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

Overview

dotenv-linter

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

GitHub Actions Coverage Status License Releases

Dotenv-linter can check / fix / compare .env files for problems that may cause the application to malfunction.

Available checks:

     Duplicated Key
     Ending Blank Line
     Extra Blank Line
     Incorrect delimiter
     Key without value
     Leading character
     Lowercase key
     Quote character
     Space character
     Trailing whitespace
     Unordered Key

What is a .env file?

     💡  A .env file or dotenv file is a simple text file containing all the environment variables of a project.
    Storing configuration in the environment variables is one of the tenets of the Manifesto of Twelve-Factor App.
    The .env file has a simple key-value format, for example: FOO=BAR.
    More information you can find in articles in English and Russian.

The key features:

     ⚡️  Lightning-fast because it is written in Rust 🦀
     💣  Can be used on any project regardless of the programming language 💥
     🚀  Can be integrated with reviewdog and other CI services (including GitHub Actions and Super-Linter) 🔥

Articles about dotenv-linter:

Dotenv-linter is created & supported by Evrone. What else we develop with Rust.

👨‍💻 Installation

Pre-compiled binary

# Linux / macOS / Windows (MINGW and etc). Installs it into ./bin/ by default
$ curl -sSfL https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s

# Or a shorter way
$ curl -sSfL https://git.io/JLbXn | sh -s

# Specify installation directory and version
$ curl -sSfL https://git.io/JLbXn | sh -s -- -b usr/local/bin v2.0.0

# Alpine Linux (using wget)
$ wget -q -O - https://git.io/JLbXn | sh -s

You can find other installation methods here: https://dotenv-linter.github.io/#/installation

🚀 Usage

Check

By default, dotenv-linter checks all .env files in the current directory:

$ dotenv-linter
Checking .env
.env:2 DuplicatedKey: The FOO key is duplicated
.env:3 UnorderedKey: The BAR key should go before the FOO key

Checking .env.test
.env.test:1 LeadingCharacter: Invalid leading character detected

Found 3 problems

🛠 Fix

It can also fix the found warnings with the fix command:

$ dotenv-linter fix
Fixing .env
Original file was backed up to: ".env_1601378896"

.env:2 DuplicatedKey: The BAR key is duplicated
.env:3 LowercaseKey: The foo key should be in uppercase

All warnings are fixed. Total: 2

🤲 Compare

In addition, dotenv-linter can compare .env files with each other and output the difference between them:

$ dotenv-linter compare .env .env.example
Comparing .env
Comparing .env.example
.env is missing keys: BAR
.env.example is missing keys: FOO

Other use cases you can find on the documentation site (https://dotenv-linter.github.io):

🚦 Continuous Integration

dotenv-linter can also be used with CI services such as: GitHub Actions and Circle CI.

🚧 Benchmark

Benchmarking dotenv-linter/dotenv-linter and wemake-services/dotenv-linter has done using the hyperfine utility:

Command Mean [ms] Min [ms] Max [ms] Relative
dotenv-linter/dotenv-linter .env 2.7 ± 0.4 2.0 4.3 1.00
wemake-services/dotenv-linter .env 162.6 ± 12.1 153.0 201.3 60.83 ± 10.20
Content of .env file used for benchmarking
 SPACED=

KEY = VALUE

SECRET="my value"

SECRET=Already defined

kebab-case-name=1
snake_case_name=2

✌️ Mentorship

Dotenv-linter is not just a linter for .env files — it is also a contributor-friendly open-source project with the purpose of helping others learn Rust using a simple, but useful tool. 😊

In addition to studying Rust, this project has another goal — to promote love for open-source, help you with the first steps in it and give an opportunity to contribute to the open-source project written in Rust. ❤️

We act as a mentor within this project and help developers follow the path of a novice contributor from start to the top. 🤗

🤝 Contributing

If you've ever wanted to contribute to open source, now you have a great opportunity:

👍 Similar projects

Contributors

This project exists thanks to all the people who contribute. [Contribute].

♥️ Sponsors

Sponsored by Evrone

Become a financial contributor and help us sustain our community.

📃 License

MIT

Issues
  • Autofix

    Autofix

    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).
    opened by evgeniy-r 34
  • Color output and --no-color option

    Color output and --no-color option

    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).
    hacktoberfest-accepted wait 
    opened by Nikhil0487 25
  • Add docs

    Add docs

    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);
    opened by wesleimp 24
  • Add compare command

    Add compare command

    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
    
    feature 
    opened by mstruebing 23
  • Release v3.0.0

    Release v3.0.0

    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:

    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

    process 
    opened by mgrachev 20
  • UnorderedKey fix

    UnorderedKey fix

    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).
    opened by evgeniy-r 19
  • Provide more short way to install dotenv-linter

    Provide more short way to install dotenv-linter

    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).
    opened by DDtKey 19
  • Provide dotenv-linter in the Arch User Repository

    Provide dotenv-linter in the Arch User Repository

    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 :)

    opened by mstruebing 18
  • Shows files that were linted

    Shows files that were linted

    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

    hacktoberfest-accepted wait 
    opened by Anthuang 16
  • Recursive search for `.env` files

    Recursive search for `.env` files

    I think it is useful that the linter can search for all env files in the specified directory, including the subdirectories. This does not prevent specifying specific files and directories input, as well as excluding them.

    What do you think?

    ✔ 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).
    opened by DDtKey 15
  • AUR release failed

    AUR release failed

    @mstruebing Hi 👋 Could you take a look at this? https://github.com/dotenv-linter/dotenv-linter/runs/2783455884?check_suite_focus=true

    opened by mgrachev 1
  • add lint id enum (#426)

    add lint id enum (#426)

    Began refactoring src/checks.rs

    • add child module check_variants
    • add Lint variants
    • refactor test setup to support the variants

    Note: this is just a checkpoint to see if i'm on the right track. Code does not compile yet!

    opened by fabricio7p 4
  • Use enum instead of string for lint's identity

    Use enum instead of string for lint's identity

    Currently, lints are recognized using string -- "DuplicatedKey", "EndingBlankLine" etc.
    It could be done by defining an Enum -- something like:

    enum Lint {
       DuplicatedKey,
       EndingBlankLine,
       ExtraBlankLine,
       // ...
    }
    

    And use it in place of &str for Warning::check_name, Check::name, and Fix::name. Lint can implement Display for printing purposes. This way, we avoid string comparison (faster code), and get safety against typos in using strings (compile time checks).

    good first issue help wanted 
    opened by atsmtat 2
  • ci: test becnmark

    ci: test becnmark

    do not merge 
    opened by mgrachev 1
  • ci: fix comparing benchmarks

    ci: fix comparing benchmarks

    ✔ Checklist:

    • [x] Commit messages have been written in Conventional Commits format;
    • [ ] This PR has been added to CHANGELOG.md (at the top of the list);
    • [ ] Tests for the changes have been added (for bug fixes / features);
    • [ ] Docs have been added / updated on the dotenv-linter.github.io (for bug fixes / features).
    do not merge 
    opened by mgrachev 3
  • Avoid making a copy of LineEntrys for warnings

    Avoid making a copy of LineEntrys for warnings

    This is a proof of concept for the fix for #410

    Store a borrowed reference instead of a copy of LineEntry inside Warning.

    First, refactored fixers to stop taking mutable Warning objects. Instead, they only talke line numbers where a fix is needed. Changed fixes::run to take a map of warning name to line numbers, instead of mutable Warnings. The caller lib::fix prepares this map by going over the warnings generated by the checker, and moves it over to fixes::run.

    Updated Warning definition to store a borrowed reference. Update Check and its implementations to use explicit lifetimes for references passed torun.

    NOTE: One side effect of this change is that warnings will be printed before backup path is printed.

    With these changes, cargo build compiles fine. cargo test would require refactoring tests first, which would be simpler after #421 and #422 are merged.

    ✔ Checklist:

    opened by atsmtat 1
  • Fixer tests refactoring

    Fixer tests refactoring

    There are two major refactoring done in this PR, both for the unit tests in fixers. This PR is also a preparation for #410

    1. Introduced a new macro lines_and_warnings which makes it easier to define input for fixer tests. Fixers work with lines and warnings, and so the tests require to prepare a Vec<LineEntry> and a Vec<Warning>. Using this macro, we avoid writing boilerplate code. It also makes it easier to change LineEntry or Warning interface in future (which will happen in #410).
    2. Added a new generic function run_fix_warnings, which takes any Fix object, and runs its fix_warnings over the lines and warnings passed in. This abstracts away the details of how lines and warnings are passed to fix_warnings. Towards that, it takes the ownership of both lines and warnings vector, so that they can be morphed into appropriate input for fix_warnings call. Fix for #410 would require changing the signature of fix_warnings.

    NOTE: I haven't committed changes converting unordered_key tests to use new lines_and_warnings macro, as it has total 22 tests. I'd do it once I get your feedback on this new macro.

    ✔ Checklist:

    opened by atsmtat 3
  • Use Rc for Warning to reduce memory consumption

    Use Rc for Warning to reduce memory consumption

    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

    good first issue help wanted 
    opened by mgrachev 18
  • Automatic changelog adding of new commits on merge in master

    Automatic changelog adding of new commits on merge in master

    Currently, everyone needs to add their changes themselves to the CHANGELOG.md file. As this is tedious work it would be great if that could be automated via a github action on merge in master or something like that.

    discussion 
    opened by mstruebing 6
Releases(v3.1.0)
Owner
⚡️Lightning-fast linter for .env files. Written in Rust 🦀
null
An extensible multilanguage static code analyzer.

PMD About PMD is a source code analyzer. It finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, and

PMD 3.4k Jun 14, 2021
SpotBugs is FindBugs' successor. A tool for static analysis to look for bugs in Java code.

SpotBugs is the spiritual successor of FindBugs, carrying on from the point where it left off with support of its community. SpotBugs is licensed unde

null 2.3k Jun 8, 2021
OpenGrok is a fast and usable source code search and cross reference engine, written in Java

Copyright (c) 2006, 2020 Oracle and/or its affiliates. All rights reserved. OpenGrok - a wicked fast source browser OpenGrok - a wicked fast source br

Oracle 3.3k Jun 14, 2021
:coffee: SonarSource Static Analyzer for Java Code Quality and Security

Code Quality and Security for Java This SonarSource project is a code analyzer for Java projects. Information about the analysis of Java features is a

SonarSource 787 Jun 16, 2021
A tool to help eliminate NullPointerExceptions (NPEs) in your Java code with low build-time overhead

NullAway: Fast Annotation-Based Null Checking for Java NullAway is a tool to help eliminate NullPointerExceptions (NPEs) in your Java code. To use Nul

Uber Open Source 3k Jun 18, 2021
Inria 1.1k Jun 16, 2021
Tackle Data-intensive Validity Analyzer

Tackle-DiVA (Data-intensive Validity Analyzer) Tackle-DiVA is a command-line tool for data-centric application analysis. It imports a set of target ap

Konveyor 4 May 18, 2021
Sourcetrail - free and open-source interactive source explorer

Sourcetrail Sourcetrail is a free and open-source cross-platform source explorer that helps you get productive on unfamiliar source code. Windows: Lin

Coati Software 11.5k Jun 18, 2021
A static analyzer for Java, C, C++, and Objective-C

Infer Infer is a static analysis tool for Java, C++, Objective-C, and C. Infer is written in OCaml. Installation Read our Getting Started page for det

Facebook 12.4k Jun 13, 2021