Chief Editor at Evrone.com
When developing applications, we always try to stick to the Manifesto of Twelve Factors. This approach helps you to avoid a number of the problems associated with the ongoing support of applications throughout their lifecycle.
One of the principles of the manifesto is that all settings should be stored in environment variables, allowing you to alter them for different environments (development, automated testing, staging/QA, production) without changing the code.
However, during development, dealing with all of these variables can quickly become cumbersome. As a project grows, it's typical for the list of environment variables it uses to grow with it, resulting in unwieldy command lines such as these:
$ RAILS_ENV=development REDIS_URL=redis://redis:6379 DATABASE_URL=postgres://postgres:postgres@db:5432 bundle exec rails server
Fortunately, there's a solution: .env files. They provide a convenient way to store all environment variables in one place, and there are straightforward libraries in many languages (including Ruby, Elixir, Python, Go, and Rust) for working with them: all they do is load the variables from the file when the application starts.
However, it's not always plain sailing. Just like in the real world, your environment needs looking after. Sometimes, problems creep in without you noticing which may impact how your application works. What kind of problems? Well, for example:
All of the problems described are situations we've run into working on real projects. For that reason, dotenv-linter was created, a tool to check .env files for problems, that could be used as part of your day-to-day workflow! A lightning-fast checking tool, or "linter", for .env files, is developed as an open source project by Mikhail Grachev, Evrone’s software engineer.
Linter tools are named after the pieces of fluff that you sometimes find stuck to your clothes and use a lint roller or sticky tape to remove: they don't necessarily do any harm, but they're not especially desirable, either.
In contrast to looking for real-life lint on clothes, linter tools often look for things which can do harm, or at the very least are ambiguous enough to be firmly recommended against — such as our list above, which of course dotenv-linter handles all of (and blazingly quickly).
dotenv-linter is written in Rust, but you don't need to have anything to do with Rust to use it — it works with any project with .env files. Pre-built binaries are available for Linux and macOS, which you can download from Github.
dotenv-linter + reviewdog
You can easily integrate dotenv-linter with reviewdog, the automated code-review tool that works with GitHub and GitLab. Just pipe the output of dotenv-linter into reviewdog using the dotenv-linter format:
$ dotenv-linter | reviewdog -f=dotenv-linter -diff="git diff master"
On GitHub, you can easily enable dotenv-linter and reviewdog on your project with a ready-made GitHub Action.
We're very happy to support the open-source projects our developers work on in any way that we can, and dotenv-linter is of course no exception, and we're pleased to have contributed the logo and brand identity to the project of our software developer Mikhail Grachev. The logo consists of an upturned letter “L”, reshaped to resemble lightning — representing the sheer speed of dotenv-linter — and we've used a red-orange hue that symbolises Rust, the language the linter's written in.
If you know Rust, and can think of ways that dotenv-linter can be improved, we'd be very happy to see you join us and help make it better for everyone. And, if you find yourself in need of developing a new useful tool, like a linter for checking code for your project, just reach out to us!
Create your free account to unlock your custom reading experience.