Create a module with helper functions encapsulating typical configuration scenarios #408

Open
ArtemGovorov opened this Issue Jan 18, 2016 · 15 comments

Projects

None yet

4 participants

@ArtemGovorov
Member

The module can be outside the core and open source.

Examples:

  • loading .babelrc (see #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
Member

Your ideas and feedback is welcome.

@okonet
Contributor
okonet commented Jan 18, 2016

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
Contributor
okonet commented Jan 18, 2016

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
Contributor
okonet commented Jan 18, 2016

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

@ArtemGovorov
Member

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
Contributor
okonet commented Jan 18, 2016

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
Member

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
Contributor
okonet commented Jan 18, 2016

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
Member

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
Contributor
okonet commented Jan 18, 2016

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
Contributor
okonet commented Jan 18, 2016

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
Member

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
Member

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.

@karlnp
karlnp commented Jan 19, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment