Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid duplicate side-effects-only require() calls #55

Merged

Conversation

nicolo-ribaudo
Copy link
Member

Comment on lines +377 to +382
var _foo3 = require("./polyfill/foo").foo;

var _foo2 = require("./polyfill/foo");

_foo2.foo;
_foo3;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we have two require calls because we first inject

import { foo as _foo1 } from "./polyfill/foo";

_foo1;

then the CJS transform generates

var _foo2 = require("./polyfill/foo");

_foo2.foo;

Then the _foo1 binding is no more available, so the polyfill provider injects a new require().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't that the bug this PR is trying to fix?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's only fixable (with a not too much compilcated logic) for require calls whose result isn't used (the first test).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the CJS transform is trying to replicate live bindings, shouldn't it find all instances of _foo1 and change them to _foo2.foo, which then shouldn't require an additional require to be added by the polyfill provider?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, and it generates this code:

var _foo2 = require("./polyfill/foo");

_foo2.foo;

Then another plugin (the one that does path.pushContainer in the test) injects a new reference to the foo "built-in":

var _foo2 = require("./polyfill/foo");

_foo2.foo;
foo;

At this point, the polyfill plugin needs to polyfill the second foo. Since require calls are not easily statically analyzable, we inject a new require rather than traversing the AST to find a variable whose value is the result of require("./polyfill/foo").

In practice this doesn't have a big effect because when using bundlers, you don't transpile to CJS with Babel: this mostly affects Node.js users, and the second require call is a noop because of the require cache.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

require calls with a string literal are just as statically analyzeable as static ESM tho.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, you definitely do transpile to CJS using babel with some bundlers. Only webpack has you transpile to ES5 but leave in the otherwise-invalid import/export statements, afaik.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main problem is that we would have to visit at least all the nodes in the top-level every time we inject a require() call for a new polyfill that misses the cache (either because it's a new polyfill, or because it was injected in ESM and then compiled to CJS). We currently don't need to do this (neither for CJS nor for ESM), because we cache what we inject. This cache is invalidated when the sourceType changes.

Anyway, this is about a few bytes that are easily gzipped (because they are exactly the same call), and that usually aren't injected (because the modules transforms runs on Program:exit, that usually is the last thing).

I'm merging this PR as-is because it solves the easy case (global polyfills), but I'll keep in mind that the pure polyfill case isn't ideal yet.

(Also Rollup and Parcel don't use Babel to compile ESM, afaik Browserify is the only popular bundler that works only with require())

@JLHwung JLHwung self-requested a review January 8, 2021 17:04
@ljharb ljharb changed the title Avoid duplicare side-effects-only require() calls Avoid duplicate side-effects-only require() calls Jan 8, 2021
@nicolo-ribaudo nicolo-ribaudo merged commit 3897273 into babel:main Jan 9, 2021
@nicolo-ribaudo nicolo-ribaudo deleted the avoid-duplicated-requires branch January 9, 2021 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants