Open kehoecj opened 1 year ago
Hi @kehoecj, I'm not familiar with this use case so wanted to understand if the --additional-file should be a filepath or filename.
I can work on this issue if this is clarified.
Can the finder code be more tolerant to unofficial extensions(such as .TOML
)? I know that the spec says that the extension should be .toml
, but some of the projects I am currently working on did use unofficial extensions.
Can the finder code be more tolerant to unofficial extensions(such as
.TOML
)? I know that the spec says that the extension should be.toml
, but some of the projects I am currently working on did use unofficial extensions.
Hi @LeslieLeung - that's a good idea. For the example you provided we could ignore case when matching files to file types. I've also seen .INI
pretty commonly used. Can anyone think of a reason not to support capitalized extensions?
@
Can the finder code be more tolerant to unofficial extensions(such as
.TOML
)? I know that the spec says that the extension should be.toml
, but some of the projects I am currently working on did use unofficial extensions.
@LeslieLeung I created a separate issue to support capitalized extensions since it should be a really straightforward implementation
This issue was old and I missed it when I opened #140 and #147
Maybe they should be addressed at the same time or being thought by having them in mind when working on this issue
cc for @vogJust who works on #154
Description
The current configuration file validator finder code recursively searches for files by file extension. Some types of configuration files do not typically include an extension such as ini files (see Ansible inventories). Options for supporting this:
Add a command line option to include extra files and metadata
Allow users to pass in a file or a string on the command line to include other files and their types. It might work something like this for the command line option:
Or like this for the the file option
custom_config.yml example:
CLI Command
Rewrite the finder code to detect each type of file (out of scope for https://github.com/Boeing/config-file-validator/labels/hacktoberfest)
This would be a much larger effort but would rewrite the finder to determine the type of each file based on content. The downside to this is that some config types are very similar (like TOML and INI) and some are supersets of other types (JSON and YAML)