There are interesting ideas in your post, but also a lot of issues. Let me try to underline them and suggest some alternative approaches.

First, there's an intrinsic security issue with using configuration files, because you're always at the mercy of inserting secrets that may be committed to your repo. You could be very self-disciplined, but maybe your newly onboarded dev won't be aware if it.

There are tools that are scanning for secrets in your repository, but if feels like saying "I'm playing with matches, but that's OK because I have a fire extinguisher".

There are also solutions to encrypt configuration files, but I strongly suggest to avoid it.

Instead, use a proper key management platform such as Azure KeyVault, Google KMS...

Second, your app should not be conscious of which environment it's running in. Having code such as `if (environment === 'dev')` is really not sustainable. As your project grows, you'll have many new environments `uat`, `staging`, etc. and maintaining all these configuration files will become really prone to errors.

Third, your app shouldn't be conscious of the underlying implementation of your configuration (such as configuration files), and only rely on environment variables (As the nodejs runtime already handles all the different implementations across OS). To do so, and if you really have to use configuration files, I suggest to not load the configuration files from the app itself as a parameter to dotenv `config()` function, but instead let the nodejs runtime load it using the `--require` command-line option, such as `node --require dotenv/config index.js dotenv_config_path=.env`. See https://github.com/motdotla/dotenv#preload