When adding node -r dotenv-vault-core/config before another script as in the documentation, in some cases you may want to be able to not (only) mutate process.env and adding the environment variables from the vault to it, but (also) saving the resulting .env file to the current working directory.
This is currently something I'm encountering in a specific case where I cannot run node -r dotenv-vault-core/config right before starting my server (because of server limitations), so I want to save the decrypted vault to /.env when running npm run build.
As a proof of concept I have forked this project and implemented something myself (here, see changes by checking the commit here), but I'm not sure if this is a good solution. Also there might be some reason to not do this. The complete build script would then look like this: DOTENV_SAVE=1 node -r dotenv-vault-core/config ./node_modules/.bin/next build.
Would something be like this a possible enhancement of this package or are there some reasons not to do this?
When adding
node -r dotenv-vault-core/config
before another script as in the documentation, in some cases you may want to be able to not (only) mutateprocess.env
and adding the environment variables from the vault to it, but (also) saving the resulting.env
file to the current working directory.This is currently something I'm encountering in a specific case where I cannot run
node -r dotenv-vault-core/config
right before starting my server (because of server limitations), so I want to save the decrypted vault to/.env
when runningnpm run build
.As a proof of concept I have forked this project and implemented something myself (here, see changes by checking the commit here), but I'm not sure if this is a good solution. Also there might be some reason to not do this. The complete build script would then look like this:
DOTENV_SAVE=1 node -r dotenv-vault-core/config ./node_modules/.bin/next build
.Would something be like this a possible enhancement of this package or are there some reasons not to do this?