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.

[ArtemGovorov]

I suppose we can also have .auto() or .guess() function that would try to guess whether or not you're using webpack or browserify, mocha or jasmine or jest, writing browser or node tests, babel or TypeScript/CoffeeScript (or both), etc.

[boneskull]

not like I have any time to volunteer, but please let me know if you could use my assistance.

[forkingpath]

On test structure: I've seen people both use subfolders and put them in the same folder as the files under test. IMO it probably depends on what fixtures/harness code you need.

[smcenlly]

Closing this issue. Wallaby's automatic configuration means that no Wallaby configuration is required for the majority of users. We'll continue to extend automatic configuration for common frameworks and usage scenarios as we become aware of them.