Hello,
I am very excited with the recent Meteor 3 release and I would like to start using all the goodies that Node 20 provides. One of those things is the --env-file flag that allows providing a custom .env file with environment variables.
So I wanted to use it for my local development and I created my .env file and then I executed SERVER_NODE_OPTIONS="--env-file=.env.local" meteor command, but it only works partially. It would appear that no matter how I set up the .env file, I still have to have the MONGO_URL and MONGO_OPLOG_URL exported before running the command.
Is there a way to make Meteor consume MONGO_URL and MONGO_OPLOG_URL provided in the .env file?
The reason why I would like to use .env file is that my Meteor app is part of a bigger suite of apps that share the same config and I wouldn’t want to duplicate env config just for my Meteor app (as I want to have 5 various .env files for different environments for my apps) and maintain my env vars in multiple places.
Welcome to Meteor forums!
Are you testing in development or from a bundle?
If you’re using a bundle, you’ll likely need to modify the line where you call Node in your Dockerfile or similar setup.
The --env-file flag isn’t a NODE_OPTIONS option. According to the docs, it’s an argument for the Node binary:
In development, Meteor calls Node internally. Meteor would need to add an option to provide additional arguments, which I don’t recall being available.
Where did you find documentation about providing this option as an environment variable?
Testing in development, no bundling. I want to containerize the development env in the future, however I cannot prioritize it yet. Therefore I am looking for easy way of leveraging .env (I started with native node support but I can move to dotenv too if it is possible)
Yes, --env-file does not work with NODE_OPTIONS, but it does work with SERVER_NODE_OPTIONS (i.e. Meteor Tool does not complain about it, however I had to completely remove my Meteor installation as I had parallelly installed Meteor 2.x and 3 tool and somehow meteor command was reverting to Meteor 2.x tool).
I did not find any info in Meteor docs about the --env-file, I assumed that any valid Node flag would work with SERVER_NODE_OPTIONS (Command Line | Docs) and so I tried that flag. Node docs for that flag are here: Command-line API | Node.js v20.17.0 Documentation
The interesting part is that if I do the following:
export MONGO_URL=valid-mongo-url
export MONGO_OPLOG_URL=valid-mongo-url
then I prepare .env.local file with following content
STUFF=test
and then I run the SERVER_NODE_OPTIONS="--env-file=.env.local" meteor command I am able to see process.env.STUFF set to test - so clearly this flag is working, only problem is that if I want to have the MONGO_URL and MONGO_OP_URL in the .env.local file when I run the same command I will end up with Unexpected mongo exit code 62. Restarting.
Apologies, clearly I misunderstood your reply, yes it is not part of NODE_OPTIONS in node but somehow node still respects it! I think it’s mostly about when the NODE_OPTIONS are passed to node vs when MONGO_URL is required by Meteor, i.e. to me it seems that mongo connection is established first before running node with NODE_OPTIONS.
I’ve never tried this new option of Node.js so I would need to play around with it to come up with more insights.
But I suspect you can run easily from the bundle as after building Meteor is not going to affect you.
See for example zCloud scripts to startup a Meteor app:
You could provide this arg to the node main.js command
So a bit different angle: is it possible to get env vars in local execution of meteor app through METEOR_SETTINGS just like we can do it in Galaxy? For Galaxy I pass the METEOR_SETTINGS in following format
{
"galaxy.meteor.com": {
"env": {
"STUFF": "test"
}
}
}
and then I am able to access STUFF via process.env.STUFF
Is it possible to replace galaxy.meteor.com part of those settings with something else to have the same functionality locally? The documentation around Meteor Settings I found (Meteor API | Docs) is a bit lackluster so I am not sure if what I want is possible (because if we could have the same thing locally then I would just write a small script that would translate .env file into METEOR_SETTINGS JSON and would have no problems).
