Dotenv-linter: линтер .env файлов



При разработке приложений я всегда стараюсь придерживаться манифеста двенадцати факторов. Такой подход позволяет избежать большого количества проблем, связанных с развертыванием приложений и их дальнейшей поддержкой.

Один из принципов этого манифеста гласит, что все настройки должны хранится в переменных окружения. Это позволяет менять их под разные окружения (Staging, QA, Production) без изменения кода.

dotenv-linter

Однако, во время разработки могут возникать сложности при работе с такими переменными. С ростом проекта, обычно также увеличивается количество переменных окружения и с ними становится не так удобно работать. Нужно каждый раз указывать их все при запуске приложения:

$ RAILS_ENV=development REDIS_URL=redis://redis:6379 DATABASE_URL=postgres://postgres:postgres@db:5432 bundle exec rails server


И тут на помощь приходят .env файлы. Они предоставляют удобный способ хранения всех переменных окружения в одном месте:

# .env
RAILS_ENV=development
REDIS_URL=redis://redis:6379
DATABASE_URL=postgres://postgres:postgres@db:5432

Для работы с .env файлами есть довольно много библиотек на разных языках программирования. Всё что они делают — это загружают переменные из .env файла при запуске приложения:

При использовании Docker и Docker Compose переменные окружения можно указать с помощью ключа environment в файле docker-compose.yml:

# docker-compose.yml
version: '2.4'
services:
  app:
    build:
      context: .
    environment:
      RAILS_ENV: development
      REDIS_URL: redis://redis:6379
      DATABASE_URL: postgres://postgres:postgres@db:5432

Но, как я уже писал ранее, с ростом проекта также увеличивается количество переменных, а вместе с ними и количество сервисов, которые необходимы вашему приложению, например Redis, RabbitMQ и т.д. И со временем, docker-compose.yml увеличивается в размерах и становится просто нечитаемым. В такой ситуации опять же могут помочь .env файлы, в которые можно вынести все переменные окружения и подключить их к docker-compose.yml с помощью ключа env_file:

# docker-compose.yml
version: '2.4'
services:
  app:
    build:
      context: .
    env_file:
      - .env


В процессе работы с .env файлами, часто могут возникать проблемы, которые можно не заметить с первого взгляда и даже пропустить при проверке кода, но которые могут стать причиной неправильной работы приложения:

1. Дублирование ключей

Такую проблему можно встретить, если в проекте есть .env файл, который содержит большое количество строк. В этой ситуации, легко не заметить появление новых переменных окружения с уже существующими ключами. В таком случае, новые переменные перезапишут старые значения:

# .env
FOO=BAR
# ...
FOO=FOO

2. Неправильный разделитель

Для удобства ключи переменных окружения можно разделять с помощью символа _. Однако в процессе разработки можно легко ошибиться и использовать другой символ, например -:

# .env
# Неправильно
FOO-BAR=FOOBAR

# Правильно
FOO_BAR=FOOBAR

3. Переменные без значения

Иногда бывают ситуации, когда нужно добавить новую переменную в приложение, но пока неизвестно, какое значение у неё будет. В таком случае обычно добавляют пустую переменную окружения. Но и здесь можно допустить ошибку, забыв указать символ =:

# .env
# Неправильно
FOO

# Правильно
FOO=

4. Некорректный первый символ

Не все знают, но есть ограничения при наименование переменных окружения. Они не могут начинаться с цифр и других символов, за исключением символа _:

# .env
# Неправильно
 FOO=BAR
.FOO=BAR
*FOO=BAR
1FOO=BAR

# Правильно
_FOO=BAR

5. Ключи в нижнем регистре

Продолжая тему ограничений, нельзя не упомянуть, что все ключи переменных окружения должны быть в верхнем регистре:

# .env
# Неправильно
foo=bar

# Правильно
FOO=bar

6. Пробелы

Ещё одной проблемой могут стать пробелы. Особенно, если они присутствуют между ключом и значением переменной окружения:

# .env
# Неправильно
FOO = BAR

# Правильно
FOO=BAR

7. Сортировка по алфавиту

Сортировка, конечно, не является проблемой, но куда приятнее работать с .env файлами, где все ключи отсортированы по алфавиту:

# .env
# Неправильно
FOO=BAR
BAR=FOO

# Правильно
BAR=FOO
FOO=BAR


Все проблемы, описанные выше, взяты из реальных проектов. На протяжение всей своей работы я постоянно сталкивался с ними, что доставляло различные неудобства в процессе разработки, а в некоторых случаях даже приводило к неправильной работе приложений.

Поэтому в один прекрасный день я решил создать инструмент, который позволил бы мне избежать подобных проблем в будущем, раз и навсегда.

И вот так появился dotenv-linter — линтер для .env файлов. Он позволяет проверить .env файлы на наличие всех проблем, описанных выше — от дублирования ключей и до сортировки.

Его ключевые особенности:

  • Молниеносно быстрый и всё благодаря тому, что он написан на Rust 🦀
  • Можно использовать на любом проекте, вне зависимости от языка программирования 🔥
  • Возможна интеграция с reviewdog и CI сервисами (включая GitHub Actions) 🚀

Установка

Есть несколько вариантов установки dotenv-linter. Самый простой вариант — скачать бинарный файл с помощью curl или wget:

# Linux / macOS / Windows (MINGW и т.д.). По умолчанию устанавливается в директорию ./bin
$ curl -sSfL https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s

# Можно указать директорию установки и версию
$ curl -sSfL https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s -- -b usr/local/bin v2.0.0

# Alpine Linux (wget)
$ wget -q -O - https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s

Другой вариант — установить через Homebrew:

$ brew install dotenv-linter

Так же есть возможность запуска dotenv-linter с помощью Docker:

$ docker run --rm -v `pwd`:/app -w /app dotenvlinter/dotenv-linter

Другие варианты установки можно найти на сайте проекта dotenv-linter.github.io.

Использование

По умолчанию dotenv-linter проверяет все .env файлы в текущей директории:

$ 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

Чтобы проверить другую директорию, достаточно передать её путь в качестве аргумента. Этот же подход работает, если нужно проверить какие-нибудь файлы по отдельности:

$ 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

Исключить какой-нибудь файл из проверки можно с помощью аргумента --exclude:

$ 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, что позволяет получать предупреждения от линтера в виде комментариев на GitHub или GitLab.

$ dotenv-linter | reviewdog -f=dotenv-linter -diff="git diff master"

При использование GitHub Actions, достаточно будет подключить к проекту dotenv-linter/action-dotenv-linter:

# .github/workflows/dotenv_linter.yml
name: dotenv-linter
on: [pull_request]
jobs:
  dotenv-linter:
    name: runner / dotenv-linter
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: dotenv-linter
        uses: dotenv-linter/action-dotenv-linter@v1

Больше информации вы можете найти на сайте проекта dotenv-linter.github.io.


С самого начала dotenv-linter разрабатывался силами Open Source сообщества.
Поэтому, если у вас есть желание поизучать Rust и заодно поучаствовать в разработке замечательного Open Source проекта, то dotenv-linter — это то, что вам нужно!
Мы будем рады любой помощи!

Similar posts

Update-informer v0.5.0

⭐️ Overview of key changes included in the new version

Dotenv-linter v3.1.0

⚡️ Overview of the key changes included in this release

GitHub Actions to guard your workflow

Automated code review with GitHub Actions 🐶

Dotenv-linter v3.0.0

⚡️Обзор ключевых изменений вошедших в новый релиз 🎉

Автоматическая проверка кода на Go

Обзор инструмента для автоматической проверки кода на Go.

Docker for Mac и Kubernetes

Небольшой эксперимент с Docker for Mac и Kubernetes.

Автоматическая проверка кода с помощью Vexor

Пошаговая инструкция, что для этого нужно сделать.

Управление зависимостями через Homebrew

Управление внешними зависимостями проекта c помощью Homebrew Bundle.

Класс Set и уникальные коллекции объектов

Рассмотрим решение одной задачи с использованием класса Set и DDD.

Настройка Passenger для работы с Action Cable

Решаем проблему работы WebSocket-сервера через Phusion Passenger.