Add support for customizing babel configuration

[chrisbreiding]

Add support for specifying babel presets and plugins, so users can override the default ones.

Implementation notes:

Potentially auto-load a .babelrc in the project root. Keep in mind that a user could have an older version of babel installed for their project that isn't compatible with Cypress's version.

Support having a .babelrc in the cypress directory that is preferred over one in the project root. Also, explore if there's a need/use case for specifying the preset/plugins in cypress.json under a babel namespace.

Write documentation detailing the current defaults and how to override them.

[paulfalgout]

This would be an excellent addition. We have a babel plugin specifically for our unit tests which lets us use a couple of webpack aliases in our unit tests without loading webpack. Once we have .babelrc support we can possibly move at least some of our unit tests into cypress. We're interested in doing this as we're finding we're doing some duplicate work setting up stubs, and it is wildly easier to setup complicated scenarios in cypress than straight mocha/chai/sinon.

[rdooh]

Looking to use something like this: https://www.npmjs.com/package/babel-root-import

in essence, what I want to be able to do is to access some util helpers with something like import { someHelper } from '~/support/utils'; instead of import { someHelper } from '../../../support/utils';, where we might want to have our specs in nested dirs for organization purposes.

Current attempt fails, perhaps because I'm unable to get this plugged in

[paulfalgout]

I do something very similar to what you are saying using babel-plugin-webpack-alias

[kentcdodds]

Chiming in with my use-case. I have some stage features of JS that aren't available in Cypress (like Object Spread). Would love to have the ability to specify a custom .babelrc :)

[nshoes]

@kentcdodds Came here to say the same thing! +1

[adamdicarlo]

Use case on my work project is accessing constants and helper functions (like Redux selectors) in the actual project from the Cypress tests.

This goes beyond configuring babel itself, though, into bundler configuration. Because using ES2015+ code from node_modules is still a messy business, and requires a shouldBabel function.

Here's what my app needs:

• Ability to specify which files do and do not get babel'd with a callback, in order to babel some packages inside node_modules:

    rules: [
      {
        test: /\.jsx?$/,
        include: ['<path to app source>', shouldBabel /* <- custom function */],
        use: ['babel-loader?cacheDirectory']
      },

• Object rest/spread syntax in imported code
• Webpack's enhanced-resolve in general (controlled by webpackConfig.resolve)
  • resolve.modules: Ability to import local app code with relative-to-root-source-dir paths (like foo/bar/baz.js) rather than relative paths (like ../../../foo/bar/baz.js)
  • resolve.mainFields: Ability to properly compile ES2015 source in node_modules via module and webpack entry points specified in package.json files (priortizing them over the main field)

[brian-mann]

Fixed by https://github.com/cypress-io/cypress/pull/888.

[kentcdodds]

Well this is a big deal :tada: Thanks!

[brian-mann]

Fixed in 1.1.0.

[chrisbreiding]

Check out how to modify the default options of the built-in browserify preprocesor or you may find the webpack preprocessor a better fit if you're already using webpack.