Mendel Config

This is an internal package that helps Mendel normalize configuration defaults, on .mendelrc or on package.json. It is used by many Mendel packages to make sure all packages use the same defaults and same merging logic.

API

var configParser = require('mendel-config');
 
// passing no options will lookup `.mendelrc` or `package.json` in the current
// folder and parent folders recursively. If not found returns default config.
var config = configParser();
 
// passing `basedir` as string or as property will make mendel lookup
// `.mendelrc` or `package.json` in the target folder instead.
var config = configParser('./sub/folder/config');
 
// which is equivalent to:
var config = configParser({ basedir: './sub/folder/config' });
 
// programmatic config only
var config = configParser({
    config: false, // prevent looking for `.mendelrc` or `package.json`
    // any other valid config
});
 
// Lookup `.mendelrc` or `package.json` and override a few params
var config = configParser({
    // any valid config, except config:false
});

Configuration parsing happens in 3 steps:

1. Merging by precedence:

Configuration precedence is, from order to strongest to weakest:

1. Passing configuration as an JavaScript object
2. Configuration on .mendelrc or package.json
3. Mendel defaults

The only exception is basedir. basedir has different meanings depending on where you declare it:

1. If basedir is passed programmatically it is meant as a configuration lookup folder
2. If any of .mendelrc or package.json is found, basedir is forced to be the folder that contains the config file, even if you provide one as property of the configuration object.
3. All other path entries that are not absolute will be relative to basedir

2. Merging by environment

Either process.env.MENDEL_ENV or process.env.NODE_ENV values can be used to configure overrides on .mendelrc.

3. Resolving relative paths

After parsing and merging all the configurations a number of path properties will be resolved relative to basedir or their "parent" configuration, for example bundlesoutdir is relative to outdir which is in place relative to basedir. Please refer to .mendelrc file configuration documentation to a full list.

4. Parsing bundles

In .mendelrc or package.json the bundles entry is an object, we will transform bundles into an array and lastly the following arrays will be flattened: entries, require, external, exclude, ignore.

Flattening is useful to use YAML references to manipulate the file lists. For example, the logged_in_bundle bellow will have all files from vendor and from main, since arrays are flattened:

# Mendel v2
 
build-dir: ./build
 
# Base/default variation configuration
base-config:
  id: base
  dir: ./src/master
 
variation-config:
  variation-dirs:
    - ./src/environments
    - ./src/settings
    - ./src/experiments
    - ./src/themes
  # dir names should be unique across all roots or mendel throws
  variations:
    # id of variation
    button_color:
      # name of the folder
      - blue_button
 
route-config:
  variation: /mendel/:variations/:bundle
  hash: /mendel/:hash/:bundle
 
transforms: # a list of all available transforms for all envs and types
  babelify-dev:
    plugin: mendel-babelify
    options:
      plugins:
        -
          - react-intl
          - messagesDir: ./tmp/strings/
            enforceDescriptions: true
  babelify-prod:
    plugin: mendel-babelify
    options:
      plugins:
        - react-intl-remove-description
        - transform-react-remove-prop-types
        -
          - react-intl
          - messagesDir: ./tmp/strings/
            enforceDescriptions: true
  custom-transform:
    plugin: ./transforms/custom.js
  envify-dev:
    options:
      NODE_ENV: development
  envify-prod:
    options:
      NODE_ENV: production
  minify:
    plugin: mendel-uglify-js
  coverage:
    plugin: mendel-istanbul
  post-css:
    plugin: mendel-post-css
    options:
      foo: bar # auto-prefixex, rtl-css
 
types:
  css:
    transforms:
      - post-css
    outlet:
      plugin: mendel-css-pack
  javascript:
    outlet:
      plugin: mendel-bundle-browser-pack
    transforms:
      - envify-dev
      - babelify-dev
    extensions:
      - .js
      - .json
      - .jsx
  node_modules:
    transforms:
      - envify-dev
 
env:
  production:
    types:
      javascript:
        outlet:
          plugin: mendel-bundle-rollup
        transforms:
          - envify-prod
          - babelify-dev
          - minify
        node_modules:
          - envify-prod
          - minify
  unit-test:
    types:
      javascript:
        transforms:
          - envify-dev
          - babelify-dev
          - coverage
 
# Order is relevant. E.g.,
# if extract-bundles comes first, we can generate lazy bundle specific css
# if css comes first, css file includes rules from files on lazy bundles
# if node-modules is last, we can use lazy-bundle as optional input (see below)
generators: # AKA graph transforms - or graph operations
  - id: extract-bundles
    plugin: mendel-extract-bundles
  - id: node-modules-generator
    plugin: mendel-extract-node-modules
 
# "outfile" is optional and only needed for single layer generation
bundles:
  main:
    outfile: app.js
    entries:
      - /apps/main
  lazy-group-1:
    outfile: lazy1.js
    generator: extract-bundles
    from: main
    extract-entries:
      - /apps/lazy
  deps:
    outfile: vendor.js
    generator: node-modules-generator
    all-bundles: true # expects only 1 bundle to apply this generator, or throws
                      # look for node_modules in every other bundle
    # alternative configuration
    # if the array don't contain lazy, the node_modules only used on lazy would
    # be kept on lazy_bundle
    # bundles:
    #   - mail_app
    #   - compose_app
  css:
    outfile: app.css
    generator: atomic-css-generator
    entries:
      - /apps/main