Expose the partial Babel config for callers to load and mutate. by loganfsmyth · Pull Request #7472 · babel/babel

loganfsmyth · 2018-03-03T03:02:04Z

Q	A
Fixed Issues?	Not necessarily fixes, but related to #5541
Patch: Bug Fix?	N
Major: Breaking Change?	N
Minor: New Feature?	Y
Tests Added + Pass?	Yes
Documentation PR
Any Dependency Changes?
License	MIT

This PR exposes .loadPartialConfig as a way to load the Babel configuration up to the point where the plugins and presets are all known, but have not yet loaded. It also exposes the path of the .babelrc and .babelignore files that Babel found, since a lot of tooling likes to toggle behavior based on whether the user has created a config file or not.

The goal of this PR is to expose enough of Babel's config that we can avoid tooling feeling like they have to implement it themselves. I think this achieves that, but if there are cases where that isn't the case I'd love to hear them.

See the README in this PR for more information, but the core of this PR is that it exposes a new first-class instance type ConfigItem that is allowed in plugins and presets lists, and the results of .loadPartialConfig ensures that each plugin and preset is a ConfigItem. From the README:

Each ConfigItem exposes all of the information Babel knows. The fields are:

value: {} | Function - The resolved value of the plugin.
options: {} | void - The options object passed to the plugin.
dirname: string - The path that the options are relative to.
name: string | void - The name that the user gave the plugin instance, e.g. plugins: [ ['env', {}, 'my-env'] ]
file: Object | void - Information about the plugin's file, if Babel knows it.
- request: string - The file that the user requested, e.g. "@babel/env"
- resolved: string - The full path of the resolved file, e.g. "/tmp/node_modules/@babel/preset-env/lib/index.js"

Beyond that, tooling can manipulate the config however they'd like before passing the config back off to Babel again.

loganfsmyth · 2018-03-03T03:03:48Z

cc @benjamn @KyleAMathews since I've talked to you two about this a little

babel-bot · 2018-03-03T03:11:25Z

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

KyleAMathews · 2018-03-03T03:18:55Z

Looks great! /cc @jquense

jquense · 2018-03-03T04:24:50Z

Neat!

danez · 2018-03-03T09:02:08Z

packages/babel-core/README.md

 const { code, map, ast } = babel.transformFromAstSync(parsedAst, sourceCode, options);
 ```

+## babel.parse(code: string, [options?](#options): Object)


Does this return the AST or something else? Maybe we can add return types so I don't have to look up the code to see what this does. :)

Sure, I'll add a note. Just realized we didn't document it when we actually landed that PR.

danez · 2018-03-03T09:06:37Z

packages/babel-core/README.md

+* `name: string | void` - The name that the user gave the plugin instance, e.g. `plugins: [ ['env', {}, 'my-env'] ]` 
+* `file: Object | void` - Information about the plugin's file, if Babel knows it.
+  * `request: string` - The file that the user requested, e.g. `"@babel/env"`
+  * `resolved: string` - The full path of the resolved file, e.g. `"/tmp/node_modules/@babel/preset-env/lib/index.js"`


This is awesome, so in theory babel-loader can add every single plugin/preset as dependency (if coming from a file) so that webpack watch will trigger a change when one of them changes.

Potentially, but since the presets aren't flattened, there are other plugins that aren't included here, so it wouldn't cover everything. Also since they are CommonJS, they'll still be cached by the module loader unless something also cleared that. I mostly exposed this since we already knew it and it seemed helpful for users. I'm figuring this will be good because they we can dump out a user's config in a human-readable format mostly.

danez · 2018-03-03T09:16:54Z

packages/babel-core/README.md

+* `babelrc: string | void` - The path of the `.babelrc` file, if there was one.
+* `babelignore: string | void` - The path of the `.babelignore` file, if there was one.
+* `options: ValidatedOptions` - The partially resolved options, which can be manipulated and passed back to Babel again.
+  * `plugins: Array<ConfigItem>` - See below.


presets are not resolved to their plugins in this case?

If they are not resolved (which I guess might be useful for some use cases) is there a way to "resolve" presets to plugins?

There is babel.loadOptions to get the fully flattened options/plugin list, but honestly I don't think manipulating that list is a good idea since it means that you're potentially changing the behavior of a preset that wouldn't otherwise be changeable.

Andarist · 2018-03-03T12:26:53Z

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

+
+export type { PartialConfig };
+
+class PartialConfig {


is there any value in this being a class?

also I havent ever understood the point of hiding "private" fields under public getters - would love to hear out the reasoning behind this structure, always seemed to me that it complicates a simple thing for no reason, especially that those getters do not have any additiona logic behind them

Mostly because I wasn't sure if we might want to add other helper methods and stuff on here in the future, but you're totally right it isn't required right now.

For instance I thought we might want a .hasFilesystemConfig() to do this.babelrc !== undefined || this.babelConfig !== undefined once we add the babel.config.js file.

Andarist · 2018-03-03T12:27:49Z

This seems super useful for other tools 👏

nicolo-ribaudo · 2018-03-04T11:40:27Z

packages/babel-core/README.md

+that callers will take the config's `.options`, manipulate it as then see fit
+and pass it back to Babel again.
+
+* `babelrc: string | void` - The path of the `.babelrc` file, if there was one.


Does loadPartialConfig only load the first .babelrc or it also loads its parents (when needed)? Also, what about babel.config.js?

It basically does everything to know what the configured plugins and presets will be, without executing them, so that includes loading all config files, and any options passed in programmatically, and merging them all together into a single config object. It just skips actually calling the plugin/presets function, and flattening the presets themselves.

loganfsmyth · 2018-03-08T02:10:33Z

Alright, I updated the PartialConfig and ConfigItem classes to have public properties instead of getters, and I added the .hasFilesystemConfig function that I mentioned.

I also updated the babel.createConfigItem to just take the same input argument format that .babelrc items have, e.g. an array if you want to pass options. I think at the end of the day the consistency is nicer, and we could always expand it later if we really wanted.

donaldpipowitch · 2018-05-07T09:48:00Z

Sorry to capture this thread, but I'm a little confused what it the idiomatic way to load a config with the Node API.

So the README for babel.transform shows this example:

babel.transform(code, options, function(err, result) {
  result; // => { code, map, ast }
});

options is linked to all available options to Babel CLI. So clearly there must be a mapping from the CLI options to the Node API options.

We have loadOptions, loadPartialConfig and createConfigItem exposed (as well as (new OptionManager().init()) which just calls loadOptions() and was the Babel 6 way to load configs). While loadOptions() seems to mimic the old behavior they actually seem to behave differently.

Say I have a .babelrc.js using preset-env and a src/foo.js containing some code. Is this difference in behavior intended?

const opts = { filename: './src/foo.js' };

const { OptionManager } = require('babel-core');
console.log(new OptionManager().init(opts).plugins.length); // 0

const { loadOptions } = require('@babel/core');
// loadOptions(opts) same as (new require('@babel/core').OptionManager().init(opts))
console.log(loadOptions(opts).plugins.length); // 23

It looks like the plugins are only resolved in Babel 7 (and only when I give it a filename).

Is the idiomatic way to load a config (e.g. is this return value of loadOptions the actual value which should be passed to transform as the second param)? Should it be done for every file?

Should I use loadOptions() at all? E.g. transformSync(data, { filename }) returns the same as transformSync(data, loadOptions({ filename })). What is the use case of loadOptions? Load options once and re-use it across multiple transformSync calls, if you know they havent' changed?

Thank you :)

Update

Or is the use case to make in-place changes to existing configs before the transformation (e.g. like here)?

loganfsmyth added the PR: New Feature 🚀 A type of pull request used for our changelog categories label Mar 3, 2018

loganfsmyth added this to the Babel 7.next milestone Mar 3, 2018

danez reviewed Mar 3, 2018

View reviewed changes

Andarist reviewed Mar 3, 2018

View reviewed changes

loganfsmyth mentioned this pull request Mar 3, 2018

Understanding usecases of manual .babelrc lookups and OptionManager use #5541

Closed

nicolo-ribaudo reviewed Mar 4, 2018

View reviewed changes

Andarist mentioned this pull request Mar 4, 2018

Support for .babelrc.js storybookjs/storybook#2582

Closed

nicolo-ribaudo approved these changes Mar 4, 2018

View reviewed changes

loganfsmyth mentioned this pull request Mar 4, 2018

[v2] Babel 7 ideas gatsbyjs/gatsby#3870

Closed

existentialism approved these changes Mar 5, 2018

View reviewed changes

loganfsmyth mentioned this pull request Mar 5, 2018

Babylon plugins #7056

Closed

SimenB mentioned this pull request Mar 5, 2018

[babel-jest] Feature: support expanded .babelrc.js api jestjs/jest#5324

Closed

Hypnosphi mentioned this pull request Mar 7, 2018

[BREAKING CHANGE] webpack 4 storybookjs/storybook#3148

Merged

4 tasks

loganfsmyth added 2 commits March 7, 2018 16:33

Expose the partial Babel config for people to load and mutate.

fef5c7e

Tweaks around PR comments.

74ab279

loganfsmyth force-pushed the expose-partial-config branch from e69413a to 74ab279 Compare March 8, 2018 02:06

loganfsmyth merged commit e42cbb4 into babel:master Mar 8, 2018

loganfsmyth deleted the expose-partial-config branch March 8, 2018 02:23

KyleAMathews mentioned this pull request Mar 8, 2018

[WIP][v2] PostCSS config experiment gatsbyjs/gatsby#4428

Closed

This was referenced Mar 15, 2018

Bump @babel/preset-env from 7.0.0-beta.40 to 7.0.0-beta.41 Bloombox/JS#55

Merged

build: bump @babel/polyfill from 7.0.0-beta.40 to 7.0.0-beta.41 yasyf/vc#515

Closed

loganfsmyth mentioned this pull request Mar 17, 2018

Have @babel/core lazy-load all dependencies and make @babel/register not explode because of that #7588

Merged

timneutkens mentioned this pull request Mar 23, 2018

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

Merged

loganfsmyth mentioned this pull request Mar 24, 2018

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

Merged

SimenB mentioned this pull request Mar 28, 2018

[request] babel-jest support custom path for .babelrc jestjs/jest#3845

Closed

tleunen mentioned this pull request Aug 22, 2018

cwd: 'babelrc' doesn't find .babelrc.js tleunen/babel-plugin-module-resolver#311

Open

SimenB mentioned this pull request Sep 10, 2018

[WIP] Upgrade entire suite to Babel 7 jestjs/jest#6949

Merged

3 tasks

tleunen mentioned this pull request Jun 7, 2019

fix(monorepo): fix babel options resolve tleunen/eslint-import-resolver-babel-module#104

Open

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

Uh oh!

Conversation

loganfsmyth commented Mar 3, 2018

Uh oh!

loganfsmyth commented Mar 3, 2018

Uh oh!

babel-bot commented Mar 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KyleAMathews commented Mar 3, 2018

Uh oh!

jquense commented Mar 3, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loganfsmyth Mar 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Andarist commented Mar 3, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loganfsmyth commented Mar 8, 2018

Uh oh!

donaldpipowitch commented May 7, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

babel-bot commented Mar 3, 2018 •

edited

Loading

loganfsmyth Mar 3, 2018 •

edited

Loading

donaldpipowitch commented May 7, 2018 •

edited

Loading