内容简介:When developing applications, we always try to stick to theOne 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
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 inmany 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:
- Key duplication. The more variables that you need to set for your application, the higher the chances you have of accidentally setting the same variable twice — when this happens, the new variables will typically overwrite the old values, but which one did you mean? And when you need to make a change, will you spot the duplicate?
- Incorrect word delimiter. Multi-word environment variable names use an underscore as a separator character (if one is used at all) — but it's easy to accidentally type a hyphen instead of an underscore and not notice it until much later.
-
Key without value.
A common tactic is to add a placeholder to a
.env
file — a variable with no value, to be filled in later; this works great, as long as you remember to go back and add the value in! - Invalid first character. Environment variables should begin with a upper-case letter or an underscore.
- Lowercase keys. By convention, application environment variables are always all-uppercase.
- Spaces. Stray spaces, especially between the variable name and equals sign, can cause problems depending on how the variables are loaded.
- Sorting by key. It's not a technical requirement for libraries to use .env files properly, but we've found that when they're sorted by key, it's a lot easier to spot some of the errors described above.
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).
Installation
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
. Instructions for fetching and unpacking the releases are shown below:
# Linux $ curl https://github.com/dotenv-linter/dotenv-linter/releases/download/v1.2.0/dotenv-linter-linux-x86_64.tar.gz -sSfL | tar -xzf - # Alpine Linux $ wget https://github.com/dotenv-linter/dotenv-linter/releases/download/v1.2.0/dotenv-linter-alpine-x86_64.tar.gz -O - -q | tar -xzf - # macOS $ curl https://github.com/dotenv-linter/dotenv-linter/releases/download/v1.2.0/dotenv-linter-darwin-x86_64.tar.gz -sSfL | tar -xzf -
If you prefer, you can install dotenv-linter on macOS using Homebrew:
$ brew install dotenv-linter/tap/dotenv-linter
Alternatively, you can use Docker to run it in a container:
$ docker run --rm -v `pwd`:/app -w /app dotenvlinter/dotenv-linter
Usage
With no parameters, dotenv-linter checks all .env files in the current directory:
$ dotenv-linter .env:2 DuplicatedKey: The FOO key is duplicated .env:3 UnorderedKey: The BAR key should go before the FOO key .env.test:1 LeadingCharacter: Invalid leading character detected
To check a different directory, or a specific file, just specify their paths on the command-line to check all of them:
$ dotenv-linter dir1 dir2/.my-env-file dir1/.env:1 LeadingCharacter: Invalid leading character detected dir1/.env:3 IncorrectDelimiter: The FOO-BAR key has incorrect delimiter dir2/.my-env-file:1 LowercaseKey: The bar key should be in uppercase
You can exclude files from the scan using the --exclude
argument:
$ dotenv-linter --exclude .env.test .env:2 DuplicatedKey: The FOO key is duplicated .env:3 UnorderedKey: The BAR key should go before the FOO key
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 .
Evrone: supporting open-source
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!
以上所述就是小编给大家介绍的《Open-sourcing dotenv-linter: a lightning-fast tool to lint .env files》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
编程语言实现模式
Terence Parr / 李袁奎、尧飘海 / 华中科技大学出版社 / 2012-3-20 / 72.00元
《编程语言实现模式》旨在传授开发语言应用(工具)的经验和理念,帮助读者构建自己的语言应用。这里的语言应用并非特指用编译器或解释器实现编程语言,而是泛指任何处理、分析、翻译输入文件的程序,比如配置文件读取器、数据读取器、模型驱动的代码生成器、源码到源码的翻译器、源码分析工具、解释器,以及诸如此类的工具。为此,作者举例讲解已有语言应用的工作机制,拆解、归纳出31种易于理解且常用的设计模式(每种都包括通......一起来看看 《编程语言实现模式》 这本书的介绍吧!