add showConfig support

[JLHwung]

Q	A
Fixed Issues?	Fixes #10617, closes #11018, closes #10538
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?	Yes
Tests Added + Pass?	Yes
Documentation PR Link	babel/website#2302
Any Dependency Changes?
License	MIT

showConfig will print the config chain applied on a specific file path by order of descending priority. It will also print the effective overrides and env config applied to a single file.

Example output (input, Full output)

(The <CWD> and <ROOTDIR> is not presented in the raw output, it is replaced by Babel's fixture runner.)

Babel configs on "<CWD>/src/index.js" (ascending priority):
config <CWD>/my-extended.js
{
  "sourceMaps": false,
  "presets": [
    "@foo/babel-preset-1"
  ]
}

config <CWD>/my-config.js
{
  "sourceType": "script",
  "plugins": [
    "[Function: (api) => ({/n  name: /"@foo//" + __dirname,/n  visitor ... ]"
  ],
  "extends": "./my-extended.js"
}

config <CWD>/my-config.js .env["test"]
{
  "plugins": [
    [
      "@foo/babel-plugin-3",
      {
        "noDocumentAll": true
      },
      "@foo/babel-plugin-three"
    ]
  ]
}

config <CWD>/my-config.js .overrides[0]
{
  "test": "src/index.js",
  "plugins": [
    [
      "@foo/babel-plugin-2",
      {
        "noDocumentAll": true
      }
    ]
  ]
}

config <CWD>/my-config.js .overrides[0].env["test"]
{
  "plugins": [
    "@foo/babel-plugin-1",
    [
      {
        "name": "@foo/inline-babel-plugin-1",
        "visitor": {}
      },
      {
        "noDocumentAll": true
      }
    ]
  ]
}

config <CWD>/.babelrc
{}

programmatic options from @babel/cli
{
  "sourceFileName": "./src/index.js",
  "presets": [
    "<ROOTDIR>/packages/babel-preset-react"
  ],
  "plugins": [
    "<ROOTDIR>/packages/babel-plugin-transform-arrow-functions",
    "<ROOTDIR>/packages/babel-plugin-transform-strict-mode",
    "<ROOTDIR>/packages/babel-plugin-transform-modules-commonjs"
  ],
  "configFile": "./my-config.js",
  "caller": {
    "name": "@babel/cli"
  },
  "filename": "./src/index.js"
}

Known limits

• It does not expand the presets
• It does not print the resolved config
• It does not tell users why certain file is ignored/excluded

These limits can be addressed in other PRs.

Additional
This PR includes commits in #11544.

[babel-bot]

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

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit a577902:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[nicolo-ribaudo]

This is awesome

[nicolo-ribaudo]

Maybe we should print in the output that in case of conflicts the first config overrides the second?

[JLHwung]

I tend to keep the output succinct. The implementation detail of config merging should be referenced from babel docs but not a debug output.

To reason how these config merges, we can print the resolved config in later PRs. Think of the Styles tab v.s. the Computed tab in the Chrome DevTools / Elements.

[hzoo]

Good hack, although I don't believe this will be the case for most plugins?

Even testing on https://codesandbox.io/s/lively-star-xv8bt, it will just print the code instead, the default plugin on ASTExplorer wouldn't even show the name until char 85.

[JLHwung]

Good catch. Well since an object has no key orders, I don't think there exists an integer N such that the plugin name is included in the (0, N) substring.

My initial thought here is to provide user at least something more descriptive/recognizable than a generic [Function] string. I have come up with several approach:

• Print Function name. It could not help much because we don't have such convention that the default export should be a named function
• Use regex to extract name: "blablabla" from function source. It doesn't work with dynamic name and has false positive.
• Actually load the descriptor. We have to initialize the API object earlier, and it may introduce breaking changes as we can end up loading a plugin twice.

So I end up with this approach and hope it could serve as an indicator so that users could know what this plugin is -- most of the time these are ad-hoc plugins not in node_modules.

[hzoo]

Use regex to extract name: "blablabla" from function source. It doesn't work with dynamic name

I think it would be really rare/weird to have a dynamic name, it's just a string? Yeah I don't think it'll be an issue in general but for standalone/repl which is a diff usecase altogether.

[nicolo-ribaudo]

I think that this is something that we can revisit with experience: I believe that the hard-to-understand function name might not be a problem for a few reasons:

1. Most people use "babel-plugin-foo" or require.resolve("babel-plugin-foo")
2. .slice(0, 50) always includes the plugin function name (or at least the first 41 characters if it's longer). This can be useful for plugins directly defined in the config file, as we do.
3. If the plugin is an actual anonymous function and the .slice(0, 50) substring doesn't contain any useful information, the person can easily see in which config file it is defined and check what's used at that index in the plugins array directly in the config file.

[JLHwung]

Do you think the following candidates are easier for typing?

BABEL_SHOW_CONFIG_FOR
BABEL_CONFIG_FOR

I don't think we can simply drop FOR because it looks like a boolean toggle

BABEL_SHOW_CONFIG=true

will never work as intended.

[nicolo-ribaudo]

I slightly prefer BABEL_SHOW_CONFIG_FOR

[existentialism]

Should we add a test for .only?

[alexkreidler]

Just a follow up: is there a reason you removed (bfdf5cf) the showConfig boolean option?

That seemed like the easiest way to use this feature.

[nicolo-ribaudo]

The reason is that it would log the config for every file processed by Babel, generating an output so big that it would hardly be useful.