3

I currently have a meteor application that is started with the following command:

meteor -p 3002 --settings ../settings.js

Inside settings.js I have a variety of variables, including some which are private (keys, etc) and some of which are more along the lines of global variables (actual settings).

I'd like to be able to have two settings files, one of which I could version control (the one with actual settings in it) and another which would be outside of version control (it would have keys, etc).

I would say that normally, I suppose the meteor way of doing this would be to use global variables somewhere inside the app for the settings. The reason I don't want to do it that way is because I have two different apps which should share these settings. There are a variety of complicated reasons that this is the case, but for now I don't really have any other way around it.

Thoughts for how I might be able to achieve this?

urban_raccoons
  • 3,499
  • 1
  • 22
  • 33

2 Answers2

1

Specifying --settings multiple times won't merge the settings, so you could try using the METEOR_SETTINGS environment variable, but see this bug.

If that doesn't work either, it unfortunately sounds like JSON-merging (pre-processing) would be the way to go. See json-merge.

Community
  • 1
  • 1
Dan Dascalescu
  • 143,271
  • 52
  • 317
  • 404
  • specifying --settings multiple times definitely doesn't work. I don't love the idea of METEOR_SETTINGS. JSON-merging as pre-processing is one of the ideas I was considering, but felt a little kludgy. – urban_raccoons Oct 23 '14 at 19:38
1

Probably the best thing to do would be to put your shared settings in a package, and then include that package in any apps that need those settings.

stubailo
  • 6,077
  • 1
  • 26
  • 32