Make the meteor command a bit more flexible


#1

The fact that I don’t want to have to remember certain settings in my Meteor projects, or want to be able to specify the settings.json automatically without having to type it (METEOR_SETTINGS still only takes json content and not a filename) prompted me to hack the /usr/local/bin/meteor wrapper (Linux, OS X) installed once when installing meteor initially.

I appended the following to the end of that wrapper

[ -f .env/meteor.env ] && source .env/meteor.env

[ -z ${METEOR_SETTINGS_FILE} ] || SETTINGS="--settings ${METEOR_SETTINGS_FILE}"

if [ "${1:-run}" == "run" ];then
    if [ ${METEOR_PORT:-0} -eq 0 ];then
        exec "$METEOR_WAREHOUSE_DIR/meteor" ${SETTINGS:-} "$@"
    else
        exec "$METEOR_WAREHOUSE_DIR/meteor" --port ${METEOR_PORT} ${SETTINGS:-} "$@"
    fi
else
    exec "$METEOR_WAREHOUSE_DIR/meteor" "$@"
fi

and then create a directory .env in my project which contains a file meteor.env. That file can contain environment variables that you would usually have to set on the SHELL, like ROOT_URL and MONGO_URL, or any of the other env variables supported.

It also adds support for two additional environment variables:

  • METEOR_PORT = the base port to run on when starting the environment (equivalent to --port option)
  • METEOR_SETTINGS_FILE = a path to the settings.json file you would like to use (equivalent to using --settings settings.kson on the command line)

Now I can document everything in my meteor.env file and simply run my projects with

meteor run

and it works every time


Suggestion: always accept settings option, even if it's meaningless
Conundrum: where to put sensitive env vars while in development?
#2

Small typo, it has to be

[ -z "${METEOR_SETTINGS_FILE:-}" ] || SETTINGS="--settings ${METEOR_SETTINGS_FILE}"

or the shell will complain that METEOR_SETTINGS_FILE is not set


#3

I came up with an alternative answer to the same problem. I wanted to be able to commit mine with my project, however.

If you look at these four files, you’ll see what I do:

  1. example.settings.json
  2. utilsJson.sh
  3. devRun.sh
  4. productionPackager.sh

So, Basically :
The first file has all possible settings for my project, whether they’re Linux environment variables or internal Javascript settings.
The second file has some simple functions for getting at the name/value pairs from bash (using jq).
I use $ ./devRun.sh instead of $ meteor.
I use $ ./productionPackager.sh instead of mup, 'coz my server is weird.