Maybe renaming master to something else like main? I think you already heard about it, but if not: master is related to a master-slave relationship, which should not be present in tech.

Maybe renaming master to something else like main? I think you already heard about it, but if not: master is related to a master-slave relationship, which should not be present in tech.

If it matters to you then I can do it.

master is related to a master-slave relationship

How about just keep the politics out of tech. master means a lot of things. A "master branch" is like a "master bedroom". You could also say it refers to the most stable code. It does not refer to slavery in any way.

How about just keep the politics out of tech.

Totally agree with you 👍

If you don't mind I propose to close the topic about renaming the branch and move on to discussing what should be included in the next release 🙂

@dotenv-linter/core What do you think about supporting multi-line values?

I think we should do 👍

What about supporting a config file?
Or is it better to save it until the next release? 🙂

I think a config file could be cool, but doesn't need to be on the top of the priority list. But of course it would be cool for 3.0.0 :)
What format do you have in mind? I would favor something like either json or toml.

What about supporting a config file?
Or is it better to save it until the next release?

Actually 3.0.0 looks saturated.
This shouldn't break backward compatibility, so I'd rather carry this over to the next milestone 🤔

What format do you have in mind? I would favor something like either json or toml.

We can also consider a popular format for configurations - yaml. How do you look at it? 🙂

I'm not to opinionated about this but somehow like the other ones a bit more. But if you feel like yaml would be better it would be fine for me.

I thought about using the yaml format because I know some linters which use it, e.g.:

• rubocop
• brakeman
• reek
• golangci-lint

Why not use ENV as the config format?

No dependencies, discourages nested clutter, quite apropos.

YAML is rather heavy, and ambiguously interpreted due to the myriad of features in can support in the full spec (I think it has undefined numbers, -0, functions, etc) - none of which is relevant to this kind of project.

Why not use ENV as the config format?

No dependencies, discourages nested clutter, quite apropos.

YAML is rather heavy, and ambiguously interpreted due to the myriad of features in can support in the full spec (I think it has undefined numbers, -0, functions, etc) - none of which is relevant to this kind of project.

We are planning to store in a config file:

1. List of excluded files:

excluded:
- dir1
- dir2/.env.test

2. List of checks:

UnorderedKey:
  enable: false

QuoteCharacter:
  enable: true
  excluded:
  - dir3/.env.test

That's an example.

Can you give an example of how to do this with ENV?

Can you give an example of how to do this with ENV?

My first question would be: Why?

That example is too hypothetical for me to be able to understand a particular use case. I'm going to counter with what I think is a practical example, and what I think a solution might be:

Example with Multiple Projects

~/.config/dotenv-linter/.envlint

~/api-project-a/.env
~/api-project-a/.env.local
~/api-project-a/.env.dev
~/api-project-a/.envlint

~/system-project-q/.env
~/system-project-q/.env.test
~/system-project-q/.envlint
~/system-project-q/sub-project-module/.env
~/system-project-q/sub-project-module/.env.test
~/system-project-q/sub-project-module/.envlint
~/system-project-q/sub-project-module/.envlint-odd

Configs might look like this, but again I don't quite understand what kind of use case would need this.

.envlint

# comma- or space-delimited list
EXCLUDED="dir1/,dir2/.env.test,dir3/"

# empty is default, otherwise TRUE or FALSE
UNORDERED_KEY=

# either 
QUOTE_CHARACTER=TRUE

# How would this even work? Looks recursively for .env-prefixed files?
# That seems weird in the first place, to me.
dotenv-linter -r ./

.envlint-odd

# comma- or space-delimited list
EXCLUDED=

# empty is default, otherwise TRUE or FALSE
UNORDERED_KEY=

# empty is default, otherwise TRUE or FALSE
QUOTE_CHARACTER=FALSE

dotenv-linter -c .envlint-odd -r ./ -r ./special-dir/

Given

• I can't see a good reason for having different config file syntaxes within the same project. This seems to go against the very idea of having a linter.
• Typically a project lint file belongs within the project.
• The tooling that runs lint commands can typically be configured to run multiple commands.

Proposal

• dotenv-linter should look for .envlint in the current directory. ONLY if it fails should it then look in parent directories, recursively. .envlint config should NOT cascade. (flat is better than nested)
• It should NOT have exclusion for things within the same project
• It should NOT have a global config with project-specific settings
• If there are very special rules, the CI/CD process should run dotenv-linter multiple times with different config files

I argue that the burden of defying common convention should fall to the defiant party, not to dotenv-linter.

I like your proposal @coolaj86 even if it feels a bit odd to me.
I like the idea to configure the tool with the same configuration language which itself is linting.
Also environment variables are there for configuring and altering run time or build time behavior, which is exactly what we are doing with a configuration file.

I would add that we could also add the files/directories which should be linted to the configuration.

RECURSIVE="./,./special-dir/`

Proposal

• dotenv-linter should look for .envlint in the current directory. ONLY if it fails should it then look in parent directories, recursively. .envlint config should NOT cascade. (flat is better than nested)
• It should NOT have exclusion for things within the same project
• It should NOT have a global config with project-specific settings
• If there are very special rules, the CI/CD process should run dotenv-linter multiple times with different config files

I argue that the burden of defying common convention should fall to the defiant party, not to dotenv-linter.

A few observations:

1. With yaml files, we can configure everything in the same way, placing them directly in the directories without project-specific configs. It's about the way the config is read, not about its format. If I understand you correctly

2. In the example with yaml (above from @mgrachev ), it was possible to exclude a file for a specific check, which I do not seem to observe in the option with ENV (at least it is not so convenient and visualised, though)

3. yaml is really handy for cases of individual hierarchical configuration, for example, the ability to select the behavior of a specific Fixer (previously there were questions about enabling/disabling a specific behavior of checks, but without a configuration file it was redundant).

But using the ENV format really makes sense from the point of view of the goals of the linter.
There is something to think about here 🤔

1. With yaml files, we can configure everything in the same way, placing them directly in the directories without project-specific configs.

I get that, but what's the use case for config in non-project directories?

Personally, I would always want linter config in the project directory and I would that that project's linter config to always take precedence over my own personal default style.

What's the opposing view?

2. it was possible to exclude a file for a specific check, which I do not seem to observe in the option with ENV

Correct, in my proposed solution you would run dotenv-linter twice. Each config file would ignore the directories (or specific files) that should be excluded.

Again, however, I don't understand the use case. I doubt that it would actually be necessary to do this. If you personally have a use case, please explain.

I understand that theoretically there are infinite permutations - I just prefer solutions that handle finite known cases because that tends to lead towards less complexity in decision making and coding.

3. yaml is really handy for cases of individual hierarchical configuration, for example, the ability to select the behavior of a specific Fixer

Tell me more. Show me a directory structure, or tell me a user story of how this could benefit people working on an open source project together, or help co-workers tame config files on-the-job, or whatever...

P.S. Not that I have any real say in this project - being more of a passerby that happened to start using it - but, if a config file is desirable, I'd like to drive towards the most likely and most well-defined uses cases.

I realized that we don't need a configuration file yet, because we don't yet understand what to store there.

Moreover, we can now customize dotenv-linter using arguments such as --skip and --exclude, or using control comments.

We are happy to announce the release of dotenv-linter - v3.0.0 🥳
Thanks to everyone who contributed to this release 🙏

Just wanted to chime in again on the master / main issue, as my opinion has changed:

Although I don't play into the politics of the day, I agree that it's just as well if master is renamed to main:

• It's a few letters shorter and it also is marginally more descriptive
• And it's a train that can't be stopped, so might as well flow with the tide
  • you may have noticed that the most recent version of git for Mac now completely breaks until you've manually set a default branch name
• Time has passed, and more tutorials for beginners are starting to use the main terminology (and being beginner friendly is perhaps a bonus)

Since github has made this a hard and fast decision (idiom meaning definite and secure, NOT difficult and hasty), and git itself is now in on the change, the change has become an issue of pragmatism IMO.