meteor / meteor-feature-requests

A tracker for Meteor issues that are requests for new functionality, not bugs.
Other
89 stars 3 forks source link

Official dotenv Support #401

Open stolinski opened 4 years ago

stolinski commented 4 years ago

tldr: Add official support for dotenv as an alternative to settings.json for private server side secrets and env config.

Preamble

I've been thinking a lot about barriers to entry for Meteor and standardizing things with the rest of the Node.js community. I feel like this is important because if there are too many foreign concepts, people will avoid Meteor because of non-transferable skills.

The What

One of these non-standard things is the use of settings.json for secrets. While I personally love the flow of settings.json, I realize that it fills your code with Meteor.settings.whatever making your code less portable and more locked into Meteor. Also, anyone learning Meteor, now needs to learn the Meteor way instead of using their existing node.js skills.

Idea

Add official support for dotenv as an alternative to settings.json for private server side secrets. The current method of using dotenv via 'dotenv' on npm is insufficient and not working in a few important cases. Here are some of the things that are not working currently with npm dotenv.

[ ] - MONGO_URL set via build tool and therefore cannot be set by dotenv without some custom code workaround. [ ] - Meteor Galaxy doesn't play well with dotenv - Having a dotenv in the root of your project will not be found by production builds and likewise with the issue above MONGO_URL still needs to be set via settings.json galaxy env rules to be found.

Ending

This isn't the most important issue in Meteor or anything, but if we want to grow this platform, I think it's within our best interests to align Meteor with the rest of the Node.js community on standards wherever possible to reduce barrier to entry for new devs coming to Meteor.

slowdownitsfine commented 3 years ago

Having to use the settings file to set MONGO_URL for galaxy deploys is really inconvenient. It would be really nice if this could be set from within the application startup code, e.g. by fetching it from an external secret store like AWS Secrets Manager.