search

kerimdzhanov / dotenv-flow

Loads environment variables from .env.[development|test|production][.local] files for Node.js® projects.
MIT License
862 stars 35 forks source link

feat(dotenv-flow): drop `.env.defaults` support #68

Closed kerimdzhanov closed 1 year ago

kerimdzhanov commented 1 year ago

Support of .env.default file is conceptually different from "dotenv-flow" and pretty well done by dotenv-defaults.

This CR drops the support of .env.defaults file to keep the concepts of these two solutions separate and clear.

kerimdzhanov commented 1 year ago

Hey @falkenhawk, any concerns?

falkenhawk commented 1 year ago

Well, we are using it to a great extent 😅 I understand the reasoning behind this PR, you want to reduce the complexity and maintenance. The suggested dotenv-defaults package does it all right, but when one would like to use also dotenv-flow features, then how to combine both? It would be awkward from a dev perspective, either in js or a cli command. And still I consider it to be the selling point when migrating from regular dotenv as I tried to describe in the original PR #29 It makes the migration painless on projects maintained by more than 1 developer - and we did it numerous times, for projects where .env file was in gitignore, we could just keep it that way, introduce .env.defaults and open the possibilities of using .local env files at the same time. Otherwise it's not trivial to migrate when .env files were already in use - there will be conflicts, painful transition period, additional communication necessary and manual steps required to move .env to .env.local, while praying that a less cautious dev does not push sensitive data to a repo. 😅

In the end it's all up to you of course, once you decide to get rid of it, we can still stick to the old version or a fork...

kerimdzhanov commented 1 year ago

Aah, I see your point. I thought that in general having a pattern like {.env.defaults + "gitinored" .env} is basically the same as having {.env + "gitignored" .env.local} …, but yeah, seamless and probably "long term" migration makes a good point, especially when you have a big team 🤔.

P.S. Thanks a lot for the quick reply and for all your contributions! I value all of them a lot ❤️