search

wemake-services / dotenv-linter

:relaxed: Linting dotenv files like a charm!
https://dotenv-linter.rtfd.io
MIT License
274 stars 9 forks source link

Feature: Ability to configure enabled violations #31

Open Levivb opened 5 years ago

Levivb commented 5 years ago

Feature request

Having a linter is cool and all, but the use case of each developer changes from case to case. I understand how a lot of these violations make sense, but there might be cases at which a certain violation should be disabled due to the implementation of the dotenv loader.

For example, see this release note of the php dot env loader: https://github.com/vlucas/phpdotenv/releases/tag/v3.0.0 which advertises multiline comments. According to https://github.com/vlucas/phpdotenv/blob/master/src/Loader.php#L16 it will only work when wrapping the value in quotes. In older versions of the loader it would even throw an exception when working with a value with spaces not wrapped in quotes: https://github.com/vlucas/phpdotenv/blob/2.5/src/Loader.php#L262

Another example, albeit less substantiated, having duplicate keys in a dotenv would be possible when the loader provides functionality similar to parsing .ini files. A valid .ini example:

[DATABASE]
database = mysqli://username:password@localhost/my_database
[ADMIN_DATABASE]
database = mysqli://admin:adminpassword@localhost/my_database

Perhaps a silly example but I hope you understand my point :P

What's wrong

There's currently no way to enable/disable specific violations. As of this moment, I can't implement this package in our pipeline due to the disallowed quoted values. For other developers, it could be any of the other violations which would prevent them from using this linter.

How is that should be

Having a way to configure the violations which are applicable to the developer would make this package a whole lot more useful since it's adoption would be a lot easier and flexible

I suggest, besides perhaps supporting the configuration of violations via cli arguments, to be able to provide a config file containing the configuration for the linter to use. A good example would be the php code sniffer which supports an xml file containing the full configuration for the code sniffer command to use. Another syntax like yaml or json would be fine as well of course.

And as icing on the cake you could even let developers configure whether an error or a warning is issued for each violation. This would make it even more useful in automated pipelines where errors are not allowed but warnings won't halt the pipeline. For example: quoted strings aren't really a big deal, so if a developer wants to, that could be a warning. While having duplicate name in your dotenv is a big no go. But this could be a separate feature request which would be dependent on this feature request.

Let me know what you think :)

As a sidenote, this feature request might depend on this feature: Test each unique violation #13

sobolevn commented 5 years ago

@Levivb absolutely agree with you. We need a mechanism to configure this tool.

First release was intentionally made as simple as possible. But, configuration is on a roadmap.