⚡️Lightning-fast linter for .env files. Written in Rust 🦀

I have implemented automatic correction of the contents of files based on the results of the check. When displaying, all warnings are marked as Fixed or Unfixed. If all warnings are fixed, exit code is 0.

Just one kind of checks is fixable for now (LowercaseKey), but I have create the scaffold for implementing all kinds of checks.

The CLI key for the autofix mode is -f/--fix.

A few comments about the design:

The separate trait Fix was made for fixes (I tried to keep some symmetry with checks), but it is possible to expand the trait Check itself with this functions too.

There are two groups of fixes: some can be implemented by working only with the line that caused warning, for others you need to work with the entire line collection.

The Fix trait allows you to work with both groups of fixes due to default function implementations.

✔ Checklist:

• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);
• [x] Docs have been added / updated (for bug fixes / features).

Closes #449

I hope this will work with GH-actions and the ubuntu-latest container. I used this locally to test some kubernetes stuff on different environments (arm64 and amd64 nodes) and it worked.

Docker Buildx is included in Docker Desktop and Docker Linux packages when installed using the DEB or RPM packages.

If you want to know more: https://docs.docker.com/buildx/working-with-buildx/

✔ Checklist:

• [x] Commit messages have been written in Conventional Commits format;
• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);
• [x] Docs have been added / updated on the dotenv-linter.github.io (for bug fixes / features).

This commit if included will:

1. Adds color to warnings,
2. Adds a --no-color option to switch off colored output,
3. Adds a test case to cover --no-color option

✔ Checklist:

• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);
• [ ] Docs have been added / updated (for bug fixes / features).

Used docsify to create the docs.

You can take a look at the docs here where I pushed my fork branch.

✔ Checklist:

• [x] This PR has been added to CHANGELOG.md (at the top of the list);

A proof of concept how comparing could work. I think this isn't the cleanest implementation and needs some abstraction work in terms of types, and duplicate work between compare and run but I wanted to see if it can work and how it could work.

We didn't already agreed that this feature needed to be added to the tool, but I liked the idea, found some time and had fun playing around with it.

So this could be the starting point of a discussion and further investigation of that topic.

What do you think?

Check this feature:

# creating test data
echo HELLO=value >> .env
echo HELLO=value >> .env.local
echo WORLD=value >> .env

# running
dotenv-linter --compare .env .env.local
# or
cargo run -- --compare .env .env.local

What should be included in the new release v3.0.0.

Features:

• [x] Color output and --no-color option (#307)
• [x] Display file names being scanned (#311)
• [x] Add compare command (#282)
• [x] Make an output on-the-fly (#335)
• [x] Add support export prefix (#337)
• [x] Add support multi-line values (#339)

Improvements:

• [x] Breaking changes: Using subcommands instead of flags (#333)
• [x] Fix a bug with QuoteCharacterChecker and values with whitespaces (#343)
• [x] Not all problems are found (#345)

Infrastructure:

• [x] Add commitlint to follow Conventional Commits (#347)
• [x] Add Conventional Commits to PULL_REQUEST_TEMPLATE.md (#347)

Site:

• [x] Add action-misspell (https://github.com/dotenv-linter/dotenv-linter.github.io/issues/17)
• [x] Change flags to subcommands (https://github.com/dotenv-linter/dotenv-linter.github.io/issues/16)

GitHub Action:

• [x] Add action-shellcheck (https://github.com/dotenv-linter/action-dotenv-linter/issues/17)
• [x] Add action-misspell (https://github.com/dotenv-linter/action-dotenv-linter/issues/16)
• [x] Add --no-color flag (https://github.com/dotenv-linter/action-dotenv-linter/issues/21)

What do you think should be included in the new release?

/cc @dotenv-linter/core

PR for https://github.com/dotenv-linter/dotenv-linter/issues/252.

✔ Checklist:

• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);
• [x] Docs have been added / updated (for bug fixes / features).

Implemented a script for more short way to install dotenv-linter (#112).

The advantage of the solution is its cross-platform. The script is executed with curl/wget and even under Windows (checked on MINGW).

Complexity is the process of automatically declaring an environment variable. In some cases, this is only possible manually at the moment.

This is a working version, I also tested on Alpine Linux.

But I would like to hear any ideas for improving or changing the approach.

Perhaps when we come to a final decision, it makes sense to create a separate repository. Although for installing binaries with a script, it looks suitable in this repo, so far it is not more than 1 file.

✔ Checklist:

• [X] This PR has been added to CHANGELOG.md (at the top of the list);
• [X] Docs have been added / updated (for bug fixes / features).

Description

The Warning struct has the LineEntry field which clones in every checks, e.g.: DuplicatedKeyChecker.

Use the Rc type for Warning to reduce memory consumption.

Similar issue: https://github.com/dotenv-linter/dotenv-linter/issues/388

The Arch User Repository is like a package repository for Arch linux maintained by it's users. I would be happy to set it up there so that any arch user can simply install it with:

<your-aur-helper> -S dotenv-linter (-S is mostly the command to install a package, in case your aur helper does it differently you need to substitute this command.

If that would be desired I would be happy to go :)

This PR adds functionality to show the files that were linted as part of a dotenv-linter run. It does so by introducing a new struct Warnings which is basically a wrapper around Vec<Warning> to also include information about the paths related to the warnings.

This PR also fixes tests as a result of the added functionality, and some refactoring.

Below shows the output from running dotenv-linter with different args:

$ cargo run
Checking ".env"
.env:1 LowercaseKey: The hi key should be in uppercase
.env:3 ExtraBlankLine: Extra blank line detected
.env:4 LowercaseKey: The hi3 key should be in uppercase

Checking ".env_2/.env"
.env_2/.env:2 ExtraBlankLine: Extra blank line detected
.env_2/.env:3 LowercaseKey: The hi key should be in uppercase
.env_2/.env:4 DuplicatedKey: The hi key is duplicated
.env_2/.env:4 LowercaseKey: The hi key should be in uppercase

Found 7 problems

$ cargo run -- -q
.env:1 LowercaseKey: The hi key should be in uppercase
.env:3 ExtraBlankLine: Extra blank line detected
.env:4 LowercaseKey: The hi3 key should be in uppercase
.env_2/.env:2 ExtraBlankLine: Extra blank line detected
.env_2/.env:3 LowercaseKey: The hi key should be in uppercase
.env_2/.env:4 DuplicatedKey: The hi key is duplicated
.env_2/.env:4 LowercaseKey: The hi key should be in uppercase

$ cargo run -- -f
Checking ".env"
Original file was backed up to: ".env_1601943961"

.env:1 LowercaseKey: The hi key should be in uppercase
.env:3 ExtraBlankLine: Extra blank line detected
.env:4 LowercaseKey: The hi3 key should be in uppercase

Checking ".env_2/.env"
Original file was backed up to: ".env_2/.env_1601943961"

.env_2/.env:2 ExtraBlankLine: Extra blank line detected
.env_2/.env:3 LowercaseKey: The hi key should be in uppercase
.env_2/.env:4 DuplicatedKey: The hi key is duplicated
.env_2/.env:4 LowercaseKey: The hi key should be in uppercase

All warnings are fixed. Total: 7

$ cargo run -- -f -q
Original file was backed up to: ".env_1601943979"
Original file was backed up to: ".env_2/.env_1601943979"

All warnings are fixed. Total: 7

$ cargo run -- -f --no-backup
Checking ".env"
.env:1 LowercaseKey: The hi key should be in uppercase
.env:3 ExtraBlankLine: Extra blank line detected
.env:4 LowercaseKey: The hi3 key should be in uppercase

Checking ".env_2/.env"
.env_2/.env:2 ExtraBlankLine: Extra blank line detected
.env_2/.env:3 LowercaseKey: The hi key should be in uppercase
.env_2/.env:4 DuplicatedKey: The hi key is duplicated
.env_2/.env:4 LowercaseKey: The hi key should be in uppercase

All warnings are fixed. Total: 7

$ cargo run -- -f -q --no-backup

All warnings are fixed. Total: 7

✔ Checklist:

• [x] This PR has been added to CHANGELOG.md (at the top of the list);
• [x] Tests for the changes have been added (for bug fixes / features);
• [x] Docs have been added / updated (for bug fixes / features).

Closes #268

Clap supports accepting multiple values in a single environment variable:

https://docs.rs/clap/3.1.10/clap/struct.Arg.html#method.env

This could be used to implement something like this:

DOTENV_LINTER_SKIP=QuoteCharacter,UnorderedKey dotenv-linter

If I pass --skip SpecificCheck, it eats all of the remaining arguments. If I do the traditional Unix thing of specifying flags before arguments, like so:

dotenv-linter --skip QuoteCharacter my/folder/.env

It completely ignores the fact that I passed a custom filename, and only checks for a .env file in the current folder. If such a file exists, it checks it. If no such file exists, it exits with a success status code (0).

If I pass the flag after the list of files to check, everything works as expected:

dotenv-linter my/folder/.env --skip QuoteCharacter

It turns out I can make the first example work by doing this:

dotenv-linter --skip QuoteCharacter -- my/folder/.env

However this is uncommon for a CLI app, and isn't mentioned as a supported behaviour in the documentation. Also I don't see any tests that cover the case of skipping checks while also passing a custom list of files.

I think the ideal solution would be to allow flags to be passed in any order. Skipping multiple checks should require passing --skip multiple times.

In certain environments, it may not be feasible to control all invocations of dotenv-linter. However the environment can typically still be controlled (and usually more easily even if invocations can be controlled). It would be nice if there was a way to set this with an environment variable.

If you have .env and .env.example files, it makes sense to compare both files to have the same keys. If you have .env and .env.local, it is quite normal to not have all keys in the .env.local file, but the keys might still have to be the same (even when sometimes a .env.local file might have completely different keys as well).

Is there a way to tell the compare command about the second situation, to compare a local overwrite file to the keys in the actual .env file?