Support `"root": true` for old config sources in v7

Feature Request

Is your feature request related to a problem? Please describe.

Babel’s previous config file loading behavior searches for config files relative to the file location. This has caused problems when users want to apply project-wide configurations to multiple packages or dependencies.

v7 now has babel.config.js which is applied project-wide, but users can no longer use config inside package.json to get the same behavior.

Describe the solution you’d like

The proposal is to add a root option to old config sources (.babelrc and package.json -> "babel"). With root: true and located in current working project’s root, the old config sources would act as babel.config.js and be applied project-wide.

Old config sources in nested packages or node_modules are ignored by default after #7358, and should still be even with root: true.

Describe alternatives you’ve considered An alternative is adding an option to babel-core that enables babel.config.js behavior for all config sources, but that can make the behavior of old config sources ambiguous for analysis tools.

Teachability, Documentation, Adoption, Migration Strategy This should probably be introduced/documented alongside babel.config.js in the v7 release. For users it’s either renaming to babel.config.js or add root: true to an old config source.

[loganfsmyth]

How would people feel about it being global: true or some other alternative? To state that the config applies to all files that Babel is told to process, similar to Browserify transform’s global option to apply a transform to all files.

We’ve already got a string-typed root option that sets the root directory that Babel uses for resolution, so I don’t want to override that, and I think a boolean root would also be easy to confuse with ESLint’s root option, which has a totally different behavior from what we’re looking to have this flag to.

[loganfsmyth]

Alright, good to know. I think at this point my preference might be to wait and see if others come to us with the same concern.

Adding another flag isn’t the end of the world, but it does mean that the file-relative and working-directory config loading have to be aware of eachother, where right now they are entirely independent. We’d also need to make our option validation system aware that .babelrc and package.json configs may have different sets of options.