juto:config

Configure meteor using node-config, allowing you to split your development and production meteor settings JSON.

Based on the ideas from 4commerce:env-settings, this provides a meteor build plugin so that you can use it as part of a meteor build command.

NOTE: This package currently uses config-gitcrypt instead of node-config , in order to provide git-crypt support.

Demo

See this repository for an example meteor project that uses this package.

Background

node-config is great for pure node applications, and 4commerce:env-settings is useful for meteor while in development.

However, when it comes to building your meteor application for deployment, if you have a cordova app then you can't use 4commerce:env-settings. This is due to a limitation of meteor's build tool, which expects a settings file. From that settings file, the Meteor.settings.public object is extracted and copied to the mobile application.

juto:config works around this limitation by providing a build plugin, which generates the settings json file needed by the meteor build command. It uses node-config to do this.

Getting started

Add this package:

meteor add juto:config

Edit your .meteor/packages file to put juto:config right near the top, just after

meteor-base (or meteor). 3. Create a folder private/config in your meteor project. 4. Create a private/config/default.json file:

1 {
2     "server": {
3         "foo": "bar",
4         "defaultServerKey": "default server value"
5     },
6     "public": {
7         "foo": "public bar"
8     }
9 }
10 ```
11
125. Create a ```private/config/production.json``` file with values to override the default ones 
13when your app is in production:
14 ```json
15 {
16     "server": {
17         "foo": "production bar",
18         "anotherServerKey": "production extra server val"
19     },
20     "public": {
21         "foo": "production public bar",
22         "anotherKey": "production extra val"
23     }
24 }
25 ```
26
276. Create a ```server/load-config.js``` file to load the config files from 
28```private/config``` and extend the global ```Meteor.settings``` object :
29
30 ```js
31 import { Meteor } from 'meteor/meteor';
32 let path = require('path');
33 
34 Meteor.startup(()=>{
35     // get the actual path of private/config/default.json
36     var filePath = Assets.absoluteFilePath("config/default.json");
37     // pass the actual path of private/config to JutoConfig.
38     JutoConfig(path.dirname(filePath));
39     // Now Meteor.settings environment has been set.
40 
41 });
42 
43 ```
44 
457. Tell [juto:config] about your setup by creating a ```juto-settings-config.json``` file:
46
47 ```json
48 {
49     "configSourcePathInPrivate":"/config",
50     "outputSettingsFiles":true,
51     "settingsProduction":"settings-production.json",
52     "settingsDevelopment":"settings-development.json"
53 }
54 ```
55 
56 This tells it to output a ```settings-production.json``` file and a 
57 ```settings-development.json``` file,
58 which you can pass to the ```meteor build```, ```meteor run ios``` or ```meteor run android``` commands.
59 
60 These files should not be used when running meteor in development mode 
61 for a web browser; Simply run it without the settings flag and let your 
62  ```server/load-config.js``` (above) do the work of deciding which settings 
63  to provide on the server and client.
64  
65 Note that ```settings-production.json``` file doesn't need to be 
66 generated yet for you to be able to pass it to a ```meteor build```
67 command; since [juto:config] provides a meteor build plugin, the 
68  file will be generated just before it is needed. So you should be
69  able to use this in a continuous integration environment.
70  
71  
72The configuration above results in the following for ```Meteor.settings```:
73
74Server - development :
75```json
76{
77"public": {
78 "foo": "public bar"
79},
80"foo": "bar",
81"defaultServerKey": "default server value"
82}

Client - development:

1{
2  "public": {
3    "foo": "public bar"
4  }
5}

Server - production :

1{
2  "public": {
3    "foo": "production public bar",
4    "anotherKey": "production extra val"
5  },
6  "foo": "production bar",
7  "defaultServerKey": "default server value",
8  "anotherServerKey": "production extra server val"
9}
10

Client - production :

1{
2  "public": {
3    "foo": "production public bar",
4    "anotherKey": "production extra val"
5  }
6}
7

Deployment tools (mup, pm2-meteor etc)

If you're using mup, mupx, pm2-meteor or some other deployment tool, just symlink settings-production.json to your required settings file (or settings-development.json if it's destined for a development server). E.g.:

mkdir .deploy_prod
cd .deploy_prod
mup init
rm settings.json
ln -s ../settings-production.json settings.json

Now protect your production data

To ensure your production keys don't accidentally end up in a git repository, you have a few options:

Option 1 - Don't store them in git at all

Use .gitignore, e.g.

private/config/production.json
settings-development.json
settings-production.json

Option 2 - encrypt them

Use git-crypt or similar, e.g.

git-crypt init
echo 'private/config/production.json filter=git-crypt diff=git-crypt' >> .gitattributes 
echo 'settings-production.json filter=git-crypt diff=git-crypt' >> .gitattributes