Cater to --settings

[timhaines]

Meteor has a --settings option now, that is used to specify a path to a json file to load into Meteor.settings. It would be nice if the buildpack catered to --settings.

I took a look at it this morning, but couldn't figure it out. Setting Heroku env var METEOR_SETTINGS is an ugly work around..

[tmeasday]

Hi Tim,

What would be a better way to do this do you think? You could have something like heroku config:add METEOR_SETTINGS_FILE=config/production.json but I feel like checking in the production settings sort of defeats the purpose.

[timhaines]

Some people like to keep things like production passwords away from their main repos right, which is why you're hesitant?

I'm not entirely clear on what the various options are, but the scenario I had yesterday wasn't dealing with sensitive information - I just wanted a way to provide various settings that should be in the production environment only. One alternative is to have our (under construction) deploy process setup METEOR_SETTINGS pulling together information from wherever it needs.

How are you dealing with this yourself?

It seems like it would be useful to cater to --settings in some way though to support what's provided by meteor.

[tmeasday]

Previously I've just used a whole bunch of ENV_VARS to define private production settings (set via heroku config:add, and read via process.env.X), which is kind of annoying when you want to do the same thing for development.

I'm not really sure how --settings is intended to be used (especially in regard to meteor deploy), and I haven't had a chance to play with it as yet. Let me know what you were thinking.

[tmeasday]

Any thoughts on this?

[sarfata]

Just migrating to heroku/meteorite and I have the same problem.

I do have production settings in a non-commited file. This works well and I am happy with this solution:

$ heroku config:add METEOR_SETTINGS="`cat settings.prod.json`"

[AdrienLemaire]

Nice tip, thanks :)

[pmuens]

@sarfata this is a very nice trick! Thanks!

👍