Allow configs to have an 'overrides' array #7091

loganfsmyth · 2017-12-22T04:31:07Z

Q	A
Fixed Issues?	Fixes #5451
Patch: Bug Fix?	N
Major: Breaking Change?	N
Minor: New Feature?	Y
Tests Added + Pass?	Yes
Documentation PR
Any Dependency Changes?
License	MIT

This does two related things

Allow every config object to specify a test/include/exclude field, just like you might do for Webpack. Each item allows an item, or array of items that can be a string, RegExp, or function.

Note, this means you could actually limit a .babelrc to only apply to some files inside of a directory, or make an env override only apply to certain files in that env, or something, which seemed like it was reasonable to allow and would be an unnecessary restriction to disallow.
Allow an overrides array of sub-configs that apply on top of the base configs that will apply based on their test/include/exclude values.

As an example, this allows user to do

{
  presets: [
    ['env', { 
      targets: { node: 'current' },
    }],
  ],
  overrides: [{
    test: "./client",
    presets: [
      ['env', { 
        targets: { browsers: ["last 2 versions"] },
      }],
    ],
  }],
}

or for instance we'll use this in Babel's own codebase to do

{
  presets: [
    ['env', {modules: false}],
  ],
  plugins: [
    ['@babel/transform-modules-commonjs', { lazy: true }],
  ],
  overrides: [{
    test: './packages/babel-register',
    plugins: [
      // Override the plugin with an empty module options config to disable lazy modules.
      '@babel/transform-modules-commonjs',
    ],
  }],
}

to enable lazy modules for everything except babel-register, where it breaks things.

loganfsmyth · 2017-12-22T04:31:29Z

This doesn't have any tests, but I'll try to add some tomorrow.

babel-bot · 2017-12-22T04:40:32Z

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/6474/

nicolo-ribaudo · 2017-12-22T14:40:07Z

packages/babel-core/src/config/config-chain.js

@@ -419,7 +546,7 @@ function matchesPatterns(

    const absolutePatterns = strings.map(pattern => {
      // Preserve the "!" prefix so that micromatch can use it for negation.
-      const negate = pattern[0] === "!";
+      const negate = pattern[0] === "!" && !disableNegation;


I think we should throw an error/report a warning if disableNegate && pattern[0] === "!"

!disableNegation is not super clear to me but I don't have a better idea.

Good call, happy to throw instead.

nicolo-ribaudo · 2017-12-22T14:43:34Z

packages/babel-core/src/config/validation/options.js

@@ -216,6 +243,9 @@ export function validate(type: OptionsType, opts: {}): ValidatedOptions {
    if (type === "env" && key === "env") {
      throw new Error(`.${key} is not allowed inside another env block`);
    }
+    if (type === "env" && key === "override") {
+      throw new Error(`.${key} is not allowed inside an env block`);
+    }


Should we also disable override in another override block?

I would say yes.

Good catch, definitely an oversight.

hzoo · 2017-12-22T18:46:43Z

Awesome really looking forward to this one! Yeah tests and some docs like https://eslint.org/docs/user-guide/configuring#configuration-based-on-glob-patterns will be useful

Allow every config object to specify a test/include/exclude

Does this include the top level config without the overrides or only in the overrides array config objects? And how do we expect this to work with only/ignore? Although I know they are different since one is about processing the files at all and the other is to change behavior

loganfsmyth · 2017-12-22T19:16:44Z

Does this include the top level config without the overrides or only in the overrides array config objects?

It includes any config object, including top-level, and env and those in overrides.

And how do we expect this to work with only/ignore?

Currently, test/ignore/exclude are processed first, so if the test doesn't match, the ignore in that config object would never be applied.

Essentially I'm separating them as ignore/only means that a file essentially doesn't get transformed at all, whereas test/... says "don't use this specific config object".

… to specific files.

…the filename is unknown.

loganfsmyth · 2018-01-05T21:14:41Z

I think this should be good now.

hzoo · 2018-01-05T22:04:15Z

Would be nice to be able to test this locally on our repo before merging (like all the other config changes)

hzoo

good with this based on tests (tbh having a hard time looking through the code with all the caching, etc)

Allow every config object to specify a test/include/exclude field, just like you might do for Webpack. Each item allows an item, or array of items that can be a string, RegExp, or function.

Not sure we want to introduce all these different ways of doing it though? array/non-array, string, regex,fn, include/exclude/test

loganfsmyth · 2018-01-06T20:10:29Z

Not sure we want to introduce all these different ways of doing it though? array/non-array, string, regex,fn, include/exclude/test

I went with it since it seemed like an established pattern in Webpack that people would be able to not have to think about a ton. The rest was taken from what we already did for ignore/only. Was there a trimmed down set of functionality you'd prefer?

hzoo · 2018-01-06T20:56:58Z

I guess it's hard to know all usecases, so not sure - like monorepo/not, app/library, webpack/node, etc. Nothing in particular, if we think that kind of parallel is good? Just wondering if it's confusing to have that kind of nested level of config but I guess doesn't mean people are going to write it that way. We probably want to provide some level of docs on basic/advanced configs with webpack soon

loganfsmyth · 2018-01-06T21:55:52Z

Just wondering if it's confusing to have that kind of nested level of config but I guess doesn't mean people are going to write it that way.

Webpack is one of the few cases where people can have fine-grained control of transforms. I imagine this config will be more likely in use for people using the CLI or gulp or any number of other integrations. I also think it could be nice for Webpack since you can still centralize all your babel configs at least.

hzoo · 2018-01-06T22:00:32Z

Ok cool, sounds good.

not really specific to the pr but: something that I was thinking of as a result of this is being able to get the files/transforms run in a debug mode for ourselves/others to better understand what babel is actually doing

nicolo-ribaudo · 2018-01-06T22:21:58Z

packages/babel-core/src/config/config-chain.js

+    (options.test === undefined ||
+      configFieldIsApplicable(context, options.test, dirname)) &&
+    (options.include === undefined ||
+      configFieldIsApplicable(context, options.include, dirname)) &&


What is the difference between test and include?

I think it's the same actually just matching webpack

Old webpack docs are gone, but I believe it used to be that test had to be a regex (e.g. /\.js$/), while include/exclude had to be a string (e.g. srcDir)? In any case, they have gained the connotations of "file type" and "directories".

nicolo-ribaudo · 2018-01-06T22:36:24Z

packages/babel-core/src/config/validation/options.js

+      throw new Error(`.${key} is not allowed inside an env block`);
+    }
+    if (type === "override" && key === "overrides") {
+      throw new Error(`.${key} is not allowed inside an overrides block`);


Nit: You can write throw new Error(".overrides is not allowed inside an overrides block");, since key is guaranteed to be overrides because of the line above.

Yeah I just felt like it was more consistent this way.

novemberborn · 2018-01-13T15:43:07Z

Is it expected that the overriding options can contain an extends clause, and the extended config can itself contain overrides, which are then evaluated?

Validation of overrides prevents such nesting, but it's currently allowed through extends. I've put an example up at https://gist.github.com/novemberborn/fdf830ce929a8641651f7838ea4efab1, compare npx babel bar.js with npx babel foo.js.

I'm not saying this behavior is necessarily wrong but it'd be good to know whether it's intentional.

xtuc · 2018-01-16T11:39:12Z

Sorry for being late at this, but super job @loganfsmyth!

simonbuchan · 2018-01-16T22:16:17Z

Reposting for visibility from my referencing comment above:

With this babel should now be able to behave like tsc, as babylon is perfectly happy to parse <type> expr with syntax-typescript so long as syntax-jsx is not also enabled.:

const common = ["@babel/env"];
module.exports = {
  overrides: [
    { test: /\.js$/, presets: common },
    { test: /\.jsx$/, presets: [...common, "@babel/react"] },
    { test: /\.ts$/, presets: [...common, "@babel/typescript"] },
    { test: /\.tsx$/, presets: [...common, "@babel/typescript", "@babel/react"] },
  ]
}

Probably something to suggest in whatever typescript docs get added? What's the roadmap on docs anyway?

loganfsmyth added the PR: New Feature 🚀 A type of pull request used for our changelog categories label Dec 22, 2017

nicolo-ribaudo reviewed Dec 22, 2017

View reviewed changes

novemberborn mentioned this pull request Jan 5, 2018

Support Babel 7 novemberborn/hullabaloo-config-manager#25

Merged

13 tasks

loganfsmyth added 4 commits January 5, 2018 12:47

Allow .env and .overrides in presets.

193e841

Allow config objects to use test/include/exclude to limit application…

f4a24a3

… to specific files.

Implement an 'overrides' config array to process in order for overrides.

c292140

Throw errors for users of 'ignore'/'only' options are passed in, but …

a76709c

…the filename is unknown.

loganfsmyth force-pushed the config-overrides branch from 54cf3b0 to a76709c Compare January 5, 2018 21:00

hzoo approved these changes Jan 6, 2018

View reviewed changes

nicolo-ribaudo reviewed Jan 6, 2018

View reviewed changes

nicolo-ribaudo approved these changes Jan 6, 2018

View reviewed changes

loganfsmyth merged commit a19349a into babel:master Jan 7, 2018

loganfsmyth deleted the config-overrides branch January 7, 2018 21:51

simonbuchan mentioned this pull request Jan 10, 2018

Simple Typescript: "Unexpected token" with Babel 7 #6959

Closed

hzoo mentioned this pull request Jan 18, 2018

Allow setting plugin options from CLI (T7190) #4161

Closed

simonbuchan mentioned this pull request Jan 23, 2018

[TS] Transform multiple assert and assign correctly #7217

Merged

loganfsmyth mentioned this pull request Feb 14, 2018

Allow more flexible file-based configuration while preventing .babelrcs from breaking things #7358

Merged

loganfsmyth mentioned this pull request Mar 23, 2018

Upgrade Babel 6 to Babel 7 (major) vercel/next.js#4050

Merged

loganfsmyth mentioned this pull request Apr 3, 2018

[v2] Refactor Babel config loading to use the new loadPartialConfig and createConfigItem APIs gatsbyjs/gatsby#4689

Closed

lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 5, 2019

lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019

Allow configs to have an 'overrides' array #7091

Allow configs to have an 'overrides' array #7091

loganfsmyth commented Dec 22, 2017

loganfsmyth commented Dec 22, 2017

babel-bot commented Dec 22, 2017 •

edited

nicolo-ribaudo Dec 22, 2017

xtuc Dec 22, 2017

loganfsmyth Dec 22, 2017

nicolo-ribaudo Dec 22, 2017

xtuc Dec 22, 2017

loganfsmyth Dec 22, 2017

hzoo commented Dec 22, 2017 •

edited

loganfsmyth commented Dec 22, 2017

loganfsmyth commented Jan 5, 2018

hzoo commented Jan 5, 2018

hzoo left a comment •

edited

loganfsmyth commented Jan 6, 2018

hzoo commented Jan 6, 2018

loganfsmyth commented Jan 6, 2018

hzoo commented Jan 6, 2018

nicolo-ribaudo Jan 6, 2018

hzoo Jan 6, 2018

simonbuchan Jan 10, 2018

nicolo-ribaudo Jan 6, 2018

loganfsmyth Jan 6, 2018

novemberborn commented Jan 13, 2018

xtuc commented Jan 16, 2018

simonbuchan commented Jan 16, 2018

Allow configs to have an 'overrides' array #7091

Allow configs to have an 'overrides' array #7091

Conversation

loganfsmyth commented Dec 22, 2017

loganfsmyth commented Dec 22, 2017

babel-bot commented Dec 22, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hzoo commented Dec 22, 2017 • edited

loganfsmyth commented Dec 22, 2017

loganfsmyth commented Jan 5, 2018

hzoo commented Jan 5, 2018

hzoo left a comment • edited

Choose a reason for hiding this comment

loganfsmyth commented Jan 6, 2018

hzoo commented Jan 6, 2018

loganfsmyth commented Jan 6, 2018

hzoo commented Jan 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

novemberborn commented Jan 13, 2018

xtuc commented Jan 16, 2018

simonbuchan commented Jan 16, 2018

babel-bot commented Dec 22, 2017 •

edited

hzoo commented Dec 22, 2017 •

edited

hzoo left a comment •

edited