webpack-contrib / webpack-canary

Canary tooling for checking webpack dependencies against specific webpack versions

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow external config file

andreicek opened this issue · comments

Use either JS or JSON, the same style that Webpack has. This would reunite all CLI flags.

Use default one webpack-canary.conf.js (TBD).

Things that need to be defined:

  • A way to define installation command (npm, yarn, custom) - related to #21
  • Combinations of webpack and dependency versions (something like webpack-to-dependency-versions.json)
  • PhantomJS / Headless Chrome options? - related to #29
  • Example folders (per version) - related to #23
  • Other options - e.g. progress - related to #25

Proposed format:

module.exports = {
  versions: {
    'v1.14.0': [{
      dependency: 'https://github.com/webpack/webpack-dev-server/archive/v1.16.3.tar.gz',
      target: 'examples'
    }],
    'v2.2.1': [
      'https://github.com/webpack/webpack-dev-server/archive/v2.3.0.tar.gz'
    ],
    'webpack/webpack#master': [
      'https://github.com/webpack/webpack-dev-server/archive/master.tar.gz'
    ]
  },
  packageManager: 'npm@5', // default is 'npm'
  chromeOptions: {}, // TBD
  progress: true
};

This looks great. Would it make sense to have the commands mapping for packageManager?

{
  packageManager: {
    exec: 'npm' // or '/usr/local/bin/npm'
    commands: {
      install: 'install',
      // etc.
    }
  }
}

If we expose the commands (if we want to support something other than npm and yarn), we would also need to support placeholders (e.g., [webpack], [dependency]). I'm not really sure we need this. For start, I would go with the basic options that cover the vast majority of use cases. Later on, we can convert the property from a string to an object without breaking compatibility.