Giters

wemake-services / dotenv-linter

:relaxed: Linting dotenv files like a charm!

Home Page:https://dotenv-linter.rtfd.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Roadmap

sobolevn opened this issue · comments

commented

Purpose

The main idea of this project is to lint .env files like this one: https://github.com/wemake-services/wemake-django-template/blob/master/%7B%7Bcookiecutter.project_name%7D%7D/config/.env.template

Architecture

This should be an installable python package. We usually use poetry for that. Here's an example: https://github.com/wemake-services/wemake-python-styleguide/blob/master/pyproject.toml

How does the linting process work?

  1. We specify grammar that will be used for parsing .env files. I guess we will use ply for that. Here's an example of how we can create a simple grammar: https://github.com/ivelum/djangoql/blob/master/djangoql/ast.py

  2. We read files that are specified by user

1.1 I will have an extra look about how LSP protocol works, so this plugin can latter be easily integrated with vscode / sublime / etc

  1. Than we parse these files with our grammar, we get list of tokens / ast nodes as a result

  2. Than we perform checks on these tokens / nodes, like we do in https://github.com/wemake-services/wemake-python-styleguide/blob/master/wemake_python_styleguide/visitors/base.py

Technical decisions

I suggest to target python3.6 and python3.7. Or two latest versions of python in the future.
I suggest to use https://github.com/wemake-services/wemake-python-styleguide and mypy for linting
I suggest to use pytest for tests
I suggest to use sphinx for docs

Team

Currently we have:

Anyone is welcome!

commented

First public release is ready!

Now, we need to concentrate on:

  • better documentation, including guides, usage example, real-life infrastructure example
  • making grammar more complex to handle multiline values, etc
  • making errors more user-friendly including better error messages, see #30
  • configuration, see #31
  • integration with editors like vscode, subl3, vim, emacs, etc. Contributions are especially welcome!
commented

@sobolevn homebrew installation will propagate the usage. 👍

commented

@brunowego absolutely! Can you please open a new issue for that?

commented

Hey @sobolevn

Do you have an ETA for this roadmap?
Especially #30 and #31 are of interest to me :)

commented

@Levivb not really, since I am quite busy on other projects.

But, if you want to contribute, I will highly appreciate that!
I will provide any help from my side.

commented

To continue with the new features we first need to setup proper testing for this project: #13 and #12
When the tests will very the baseline we can start with ignoring violation and comment configuration.

@kaelscion welcome on board! You are now a collaborator of this project. 🎉

commented

Nice project! Is auto-fixing errors within the scope of this project? This would then match the behavior of other pre-commit hook implementations (like black, isort etc.)

commented

I would love to have this merged, but implementing this feature is not on my schedule :)