babel-register: Fast path without transpilation/source-map-support when no plugins are enabled?

[papandreou]

Choose one: is this a bug report or feature request?

Feature request

I'm introducing babel and babel-preset-env in a project (unexpectedjs/unexpected#416) where the main development takes place in bleeding edge node, but the code has to be transpiled to work in older node.js versions (including on CI) and in older browsers.

Since node.js 8.3.0+ has a fairly complete ES201[567] implementation I thought I'd use that as the baseline so I wouldn't need to transpile anything in my main edit->save->test cycle. I expected babel-preset-env to just bypass the transpilation pipeline when none of the configured plugins are required in the running environment. It could simply unhook itself from require.extensions and not bother installing source-map-support.

The reasons why I'd like it to work like that are:

1. Performance. I want my dev cycle to be fast. In this particular project I measured a difference of half a second between babel-register being active with no active plugins (warm cache) vs. not being required at all.
2. Fewer layers of complexity wrt. the code being executed. Sometimes the transpilation is a leaky abstraction, has bugs of its own, and causes weird or mangled entries in stack traces. It'd be nice if those things didn't affect me while developing.

My .babelrc looks like this:

{
  "presets": [
    ["env", {
      "modules": false,
      "targets": {
        "node": "current"
      }
    }]
  ]
}

babel-preset-env's debug mode displays an empty list of plugins when I run it in node.js 8. However, I can tell that despite this fact, babel is still burning cycles processing and reserializing all my code. This results in a performance degradation of about half a second compared to removing --require babel-register from the mocha command line.

Since the premise of babel-preset-env is to dynamically adjust the amount of work that has be done, I expected it to disable babel's require hook altogether when the platform has all the required capabilities. The alternative would be for me to wrap babel-register in a module of my own and only execute the require when using node.js < 8.3.0, then use that instead of babel-register. However, that's hard to get to work with tools that include native babel support (such as jest), and the exact cutoff point is subject to change. To me it feels like something that babel itself should take care of.

I brought up the issue/idea in the slack channel here: https://babeljs.slack.com/archives/C0DFJT81H/p1503758913000063

There was a productive discussion, some potential caveats were brought up, but the idea of a fast path when no plugins are configured was not flat out rejected, so I'm taking the liberty of raising it here :)

Thanks in advance for considering it!

Your Environment

software	version(s)
Babel	6.26.0 and the 7 betas
node	8.4.0
npm	5.3.0
Operating System

[babel-bot]

Hey @papandreou! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[ljharb]

Wouldn't you want the dev experience to mirror the CI/prod experience, "bugs of its own" and all?

[papandreou]

@ljharb, that would be nice, of course, but since it's still a relatively rare occurrence, I can live with CI catching those cases.

[papandreou]

I made a module called maybabel that helps me achieve what I want. It's inferior to having babel-preset-env determine the capabilities at runtime, so I still hope you'll consider this feature request.

[hzoo]

Also similar to #5890. If we can determine nothing is run we should just return the file sure, would appreciate a pr if you want this earlier since we are trying to release v7

[loganfsmyth]

Revisiting this, I'd be open to this as a Babel option like requirePlugins: boolean that would just return null; like we do when something matches ignore or fails to match only.