Create a module with helper functions encapsulating typical configuration scenarios

[ArtemGovorov]

The module can be outside the core and open source.

Examples:

• loading .babelrc (see Add support for .babelrc #208),
• configuring webpack,
• loading and configuring TypeScript config file,
• etc.

The API may look like (or something similar):

var config = require('wallaby-enhanced-config')
// will load babelrc, add webpack postprocessor, etc.
module.exports = wallaby => config.babel().webpack({...})({
  files: [...],
  tests: [...]
});

[ArtemGovorov]

Your ideas and feedback is welcome.

[okonet]

I think this should be taken to a next level. Something like presets/plugins for babel or eslint. For example: https://babeljs.io/docs/plugins/preset-es2015/

I would like to be able to configure wallaby in package.json with something like:

{
    "wallabyConfig": {
        "plugins": ["mocha", "webpack", "babel"]
    }
}

This should then parse files / tests sections from mocha config, add webpack pre-processor and use .babelrc from the root of the project config.

[okonet]

The presets concept with extends would be also practical. So everyone could share wallabyConfig between team members like you can now share your eslint/stylelint configs as a separate npm package.

[okonet]

So the goal should be "no configuration", especially for projects that already have a configured test runner for CI etc.

[ArtemGovorov]

I like the idea, but importing/sharing tests/files can be an issue: karma/mocha don't separate tests/files, but wallaby needs to know exactly what are the test files. So wallaby needs a bit more information than is stored in a configured test runner for CI.

[okonet]

Well, in this case it should fall back to some sane defaults. These defaults could be then overriden in the config, but for most people there should be no work to start using wallaby.

[ArtemGovorov]

Another thing is that users (especially those who don't use webpack/browserify) may want to configure some files to not instrument them (like libs). It may be impossible to guess this without some configuration.

[okonet]

Also can be done with defaults I assume. Most people put libs into /vendor or similar. In case they don't — they can override it in the config.

[ArtemGovorov]

sane defaults

What would be in your opinion sane defaults for a tests pattern?

I have seen tests/test/spec/specs folder with *Spec.js/*-spec.js/*-test.js/*Test.js patterns used a lot. Quite a few people have __tests__ subfolders in source folders.

[okonet]

I think each modern testing framework/runner has its own, so it's easy to follow IMO:

Jest people using __tests__ as a subdirectories: https://github.com/facebook/jest/tree/master/src/__tests__

Mocha uses /tests/test/spec/specs etc as you wrote above.

etc.

[okonet]

Probably you're right and files and tests are hard to guess and they can be required properties for a config. But the rest (loading babel / webpack config) should be done automatically with plugins. This is there most pain is hidden.

[ArtemGovorov]

babel, webpack, typescript, SystemJs, chai fluent support with encapsulated pain will be pretty straightforward to support as a separate module. Later on, if we find a way to guess files/tests from other configs, we may just build the next level that you're suggesting on top of the module.

bootstrap function can already be supplied as a string, so should be possible to say .chai().webpack() and generate both chai globals and webpack bootstrap.