How do we want to handle `.babelrc` lookup in 7.x

[loganfsmyth]

Edit 2

Most recent status: #6766 (comment)

Edit 1

All below still applies, but also see more explanation in #6766 (comment)

Original:

Not a fleshed out proposal, but filing for tracking and discussion.

Currently if you have:

.babelrc
src/
  index.js
  utils/
    .babelrc
    other.js

compiling index.js will use the root-level .babelrc, and other.js will use the src/utils/.babelrc. I assume this pattern was pulled from other utilities like ESLint, but not 100% sure.

We're at the point now where this approach has become a problem for us because:

1. Very few people seem to expect this behavior to begin with.
2. People expect their project-level .babelrc file to also apply to things that live in node_modules. Babel 6 was terrible at figuring out how to handle node_modules because it always assumes things are strict mode, and always rewrites this, but a lot of those issues aren't as big in Babel 7, or at least ideally won't be, because we plan to have better handling of the sourceType: script vs sourceType: module distinction. This kind of works now, but see point (3).
3. If people publish packages to npm and include .babelrc files in their packages, or more troublingly, use the babel key in package.json (which you can't really get around publishing), users trying to use Webpack or anything like it to compile node_modules get extremely confusing errors about not being able to find plugins and presets referenced in those files. See Enable babel-preset-env for node_modules that target newer Node versions facebook/create-react-app#1125 for a massive list of users that want to compile node_modules, but would absolutely be bitten by this issue.

So where does that leave us? The simplest thing I can think for us to do would be to change up Babel's API to, by default, accept a root directory as an argument where it would search for the config, defaulting to the working directory.

We're already at a point where I've thought about adding an argument for root directory to resolve the filename relative to, so that should be uncontroversial. Actually changing config resolution is a bigger question.

It would be pretty easy for us to allow users to opt for the old behavior, so I think my proposal would probably be to add this new root-dir config resolution logic and make it the default, but keep the old behavior around as an opt in. So where now we have

babelrc: boolean

to toggle config resolution off and on, I could imagine us doing

babelrc: true | "root" => Look for config in root directory
babelrc: "relative" => Look for config, starting from compiled file, working upward
babelrc: false => Skip search entirely.

instead.

The primary loss of functionality here is that if users do want to use .babelrc files inside nested folders to change Babel configs based on path, they don't have an easy way to do it anymore. I don't however have a good grasp of how many users that might be. It seems like we may want to consider #5451 as something to be included in this effort if we do want to change, which might end up blocked on #6765.

[hzoo]

Seems totally reasonable to me

• I haven't ever seen a nested babelrc file, not sure how we can find out
• I assume everyone would want to transform all their code in the same way (sounds hard to debug/understand)
• Most people have 1 babelrc so they would assume Babel only would look at that config. I would be surprised it would try to read a babelrc from node_modules
• Default to the intuitive behavior that helps us support new use cases while providing an opt-out sounds good to me 👍 👍 let's do it.
• Given we ourselves liked using overrides for ESLint yeah we can consider [Feature Request] feature similar to ESLint "overrides" (config based on glob) #5451

[kentcdodds]

Thanks for all your work on babel folks! 👏

Here are some thoughts:

• I really like ESLint's model. I like the whole thing, in particular how the root: true functionality works and just minutes ago was looking to see if babel had support for something like this. I'm not even joking.
• I don't ever want to transpile node_modules, but I think that it should be possible and I would expect that the hierarchy should apply there as well. I can't speak too much to this though because I'm not big on the idea of transpiling node_modules. I just feel like there's probably a use case for it. But making it a little difficult to do isn't a bad thing IMO.

I hope that's helpful! Thanks again!

[hzoo]

@kentcdodds

There is a babelrc: false option which stops lookup as mentioned ^

Compiling node_modules is for when you want to consume a package from npm that is ES2015+. Maybe you support a different environment so you need to compile it down to a different level than ES5. Example: maybe a react package uses async but you don't want to use the "main" file which uses regenerator, so you want the package to output async. It may or may not be transpiled to async (no change), generators, or regenerator depending on the users preset-env targets

Ya it's interesting that eslint would never have this issue since there's no need to look at node_modules there 😛

[kentcdodds]

There is a babelrc: false option which stops lookup as mentioned ^

👍

Solid use case example 👍 So long as it's possible that'd be good with me. And if I could disable the lookup using webpack/babel-cli etc. then that'd be sufficient I think

[niieani]

How about non-precompiled/non-distributable monorepos? This is currently what we do at @futuresimple, so e.g. we have packages/pkg-name, each with its own version of .babelrc that can vary across the packages in the monorepo. On the other hand, the root folder (repository root) doesn't have any babel config.

To handle such a case well, I think the default behavior should be to use the .babelrc next to the closest package.json, rather than closest to the file (as is now).

[sokra]

I've seen nested babelrc files in repos which contain server and client build.

[hzoo]

I'm sure not everyone here will have read everything but we could possibly do #5451 which is an "overrides" option similar to eslint which gives you glob config + different config so you don't need nested .babelrcs.

[nicolo-ribaudo]

I'm strongly in favor of only using the root babelrc, since config files in nested directories are really easy to miss.
If people want more control on their builds, they can use tools like gulp.

+1 for #5451

[niieani]

@hzoo #5451 won't help for monorepos (when used without a build step). You'd have to re-declare all the babelrc's in the root of the monorepo, which doesn't sound fun.

When you install packages in a monorepo, they end up symlinked as node_modules/MONOREPO_PACKAGE.
Since each package can have its own .babelrc, we depend on babel resolving those .babelrc's to transpile the code from those modules using the settings they declare.

I am all for this change, as long as it's possible to declare in the root .babelrc something like deepResolveBabelRc: true. Having this as a programmatic option in the API (as proposed in the issue) won't work for cases where we'd like to directly run: node -r babel-runtime node_modules/MONOREPO_PACKAGE/script.

[loganfsmyth]

@niieani Do you have example where you require different babel configs for different packages in a monorepo? I'd have thought they'd be very similar, and thus something like #5451 might be enough for your case.

[Andarist]

@loganfsmyth I imagine when having both front end and back end code in your monorepo you can have different babel configs. Also personally I like to be explicit about my deps, even used transforms, and I do not include a jsx transform when transpiling utility library even though in other directory of the monorepo I have a React UI library

[niieani]

@loganfsmyth exactly as @Andarist says. We have both CLI and Frontend packages in the monorepo, at the same time we'd like to be able to open source some of the packages, so each package in the monorepo should be able to be run without the dependency of the root directory of the monorepo. #5451 introduces such a dependency, i.e. the package won't work when it's moved out of the monorepo into it's own repository via a git subtree.

[loganfsmyth]

Sounds good, thanks for the clarification. So it is not that there is are package-level .babelrcs that might merge with the one at the monorepo root, it's essentially that each inner package could be thought of as having its own root.

[Andarist]

As for me - that would be desired. If I'd like to extend some other config I might do that easily with .babelrc.js, but in most cases I just want to keep specific babel config per package, even if they all live in monorepo at the moment.