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
Check arbitrary (supported) files #127
Comments
Thanks for your suggestion!
You're talking about TomlFormat and YamlFormat classes, right? They are still kind of raw, changes will be needed to turn them into generic parsers for any .toml or .yaml file.
The whitelist is used to validate the style strictly, and explicitly inform which files you want to be parsed. [nitpick.JSONFile]
file_names = ["package.json"] ... to validate the I don't remember the code by heart. Another issue for generic TOML and YAML parsers: what to check?
Still a very limited check. For TOML and YAML files, a similar approach could be used. Some possibilities I see for TOML files:
Some possibilities I see for YAML files:
Currently, Nitpick handles a YAML file ( There are many Nitpick validation possibilities for generic file parsers. If you could share examples of excerpts from the files you would like to check (Prettier and Azure Pipelines config), we could come up with a generic style file syntax for them. |
Thank you for your thoughtful reply.
As I see it, from a user perspective and not from a code perspective, that is a feature. It could potentially evolve in "any new section describes a new file". It is true that having a generic parser raises many points. I agree with you, the feature request is vague and covers too much at once. I can create new feature requests for the new file we would like to have support for. And close this one for reference, as a "Won't fix"? |
I agree, it is a feature that makes things easier. If you want, you can create this new feature request.
Perfect. |
With 6f54480 the code is working like this for JSON and text files: a new section describes a new file. It will be available on the next release. |
I feel that is the right behaviour. The text plugin does the same thing i suppose. I did ran into a catch with that plugin though. The text plugin and presumably others also check if the file type matches. Overall the above suggestions all seem reasonable. I do want to add gitlab yaml to the list of desired files to support. |
Hi @hmvp, thanks for the enhancement and bug reports so far.
A YAML file is also a text file:
But I'm using nitpick/src/nitpick/plugins/text.py Lines 76 to 77 in 5b1dd68
Initially I thought "all files can also be text files, so I can use 'contains' with any file". Could you open another bug with the style you used and failed?
Which kind of validations you would like to do in
I ask because I'd like to understand real use cases, and then think of a generic and extensible API.
I like the "contains" approach so far, although I did it mindlessly on the JSON plugin, and in more extensible way on the text plugin. |
So the thing I tried to do is this check:
Of course that was using the text plugin so with yaml support it would be nice if I can assert that (partial) line is present under a specific section. Maybe the regex option is also relevant here |
Hi @bibz @hmvp @jaysonsantos. 👋🏻 This issue might actually have a future. I'm not sure about the API, I would appreciate some feedback from you. 🙂 Thanks! |
Expected Behavior
Similar to the "[nitpick.JSONFile]" section, arbitrary TOML, YAML, etc. files can have content enforcement.
Current Behavior
With the notable exception of JSON files, there is a definitive list of supported files that one has to abide by.
Even though the formats are parsed and handled by nitpick, the files are not on the whitelist.
Possible Solution
Rely on the filename extension to apply the format checker instead of using a whitelist.
Context
We would like to enforce new configurations with nitpick:
Prettier can also parse a JSON configuration, but we would ideally not rewrite the configuration and open the door for more of our YAML files.
The text was updated successfully, but these errors were encountered: