Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a Linter / Validation System #56

Open
ovflowd opened this issue Aug 5, 2024 · 4 comments
Open

Introduce a Linter / Validation System #56

ovflowd opened this issue Aug 5, 2024 · 4 comments

Comments

@ovflowd
Copy link
Member

ovflowd commented Aug 5, 2024

This is another feature we want to tackle and have within the API docs tooling. The idea is similar to ESlint: We have a system that reports on irregularities when running the API docs tooling against files.

Assume you have a missing version on one of the YAML metadata (i.e.: version: REPLACEME), or some of the YAML is missing (like each module may have an "introduced_in" on the first node/section), or you have some invalid type within the API docs (ie: {SomethingThatDoesNotExist} or a typo {Obrect} instead of {Object}

  • The system would print on the console with the error level (info, warn, error) and tell in which line and position it would be such an issue on the source Markdown file.
  • The system could be a singleton that collects all issues during runtime and then displays them at the end of the run.
  • The system could be disabled/ignored with a CLI flag --skip-validation;
    The system must know the almost exact position of something, possibly within the AST tree, which gives you a position object for each item so you can narrow it to a close position.
  • Some methods might need to be updated (if they don't use a node (ApiMetadataEntry or Parent/Node) to pass such information or the position object; Or maybe some abstraction so that the queries.mjs, generators.mjs and all utils know what is the current context being handled. (Note that since parsing and processing is async, we cannot set a static context within a Singleton)
    The system should not use try/catch or exceptions since the code should be evergreen and failproof to actual errors within the markdown.
  • All the message templates should be defined within the constants.mjs
  • When there's at least one Error level, the process will exit with a non-success status code.

Possible items for the system:

  • Warning: missing version on a YAML metadata entry (changes or updates properties)
  • Warning: invalid version on a YAML metadata entry (changes or updates properties) (ie: REPLACEME)
  • Warning: invalid type reference {type}
  • Info: missing "introduced_in" on top of the document
  • More?
@flakey5
Copy link
Member

flakey5 commented Sep 10, 2024

I can try to take a swing at this once I'm done with the legacy json generator, do we know when we'd want this by?

@ovflowd
Copy link
Member Author

ovflowd commented Sep 10, 2024

I can try to take a swing at this once I'm done with the legacy json generator, do we know when we'd want this by?

No ETA, priorities on parity with current generation.

@flakey5
Copy link
Member

flakey5 commented Sep 10, 2024

Assuming this is also gonna be ran in ci, wdyt of having it report errors inline similiar to https://www.npmjs.com/package/@reporters/github?

@ovflowd
Copy link
Member Author

ovflowd commented Sep 10, 2024

Why not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants