support locating multiple configuration files

configuration like this:

new Liftoff({
  configFiles: {
    '.app': {
      extensions: ['rc','.yml'],
      search: {
        cwd: {
          path: './',
          findUp: true
        },
        myHomeKey: '~',
        etc: '/etc'
      }
    },
    'appfile': {
      extensions: function () {
        return Object.keys(require.extensions)
      },
      searchPaths: {
        baseDir: {
          path: './',
          findUp: true
        },
        home: '~',
        alternate: '/path/to/alternate',
        multiple: ['/path/to/whatever', '/path/to/something', '/path/to/something/else']
      }
    }
  }
});

yields environment like this:

env.configFiles = {
  '.app': {
    cwd: '/var/www/project/code/.apprc',
    myHomeKey: '/Users/user/.apprc',
    etc: null
  },
  'appfile': {
    baseDir: '/var/www/project/code/appfile.js',
    home: null,
    alternate: null,
    multiple: ['/path/to/whatever/appfile.js', '/path/to/something/appfile.js']
  }
};

~ expands to process.env.HOME || process.env.HOMEPATH || process.env.USERPROFILE searchPath entries which specify an array of paths should NOT perform findUp on each entry.

[phated]

Support for this was just published as 2.3.0

[sttk]

@phated Thank you for answering my questions.

That would mean dropping the array syntax … or stopping traversal after the first match; which do you think is better?

If every result is a singular string, I also think that dropping the array syntax is better because it makes less confusing for users and I can’t think the cases in which the syntax is used.

… If there is a gulpfile.js and a gulpfile.babel.js in a project, which is used?

Liftoff preferentially uses an earlier extension in specified order. (Though it isn’t guaranteed.)

I don’t think configFiles should accept an array or string and should only accept an object.

I got it. I’ll do so.

… nothing in the key is expanded (e.g. ~ is not expanded to home) and only valid path characters should be allowed as keys.

I got it. I’ll implement not to expanded ‘~’ and ‘.’ but to use the key just as user specify.