Add a 'lazy' options to modules-commonjs #6952

loganfsmyth · 2017-12-01T23:48:57Z

Q	A
Fixed Issues?
Patch: Bug Fix?	N
Major: Breaking Change?	N
Minor: New Feature?	Y
Tests Added + Pass?	Yes
Documentation PR
Any Dependency Changes?
License	MIT

Not inspired by the code from https://github.com/zertosh/babel-plugin-transform-inline-imports-commonjs itself, but certainly inspired by talking to @zertosh about it in the past, and now feeling like we might want to use it for Babel's own codebase. It's pretty trivial to include in our helper-module-transforms so I figured why not.

Allow import bindings to lazy-initialize themselves the first time they are accessed, instead of up front at file load time.

babel-bot · 2017-12-01T23:57:13Z

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

danez · 2017-12-02T11:27:34Z

packages/babel-plugin-transform-modules-commonjs/src/index.js

+    typeof lazy !== "function" &&
+    (!Array.isArray(lazy) || !lazy.every(item => typeof item === "string"))
+  ) {
+    throw new Error(`.lazy must be a boolean, array of strings, or a function`);


Is the . at the beginning intentional?

It's because it's a key in the configuration.

I guess we don't really have a good naming scheme for these errors. I just included it since it is an object property. I can change it.

At least this is consistent with the other error messages used in Babel but it's not super clear to me. What about: "the key 'lazy' in the Babel configuration must be a boolean". Can be done in a second PR. That reminds my that I still have a PR to add code frames to configuration issues. I can continue my work, what do you think?

What about: "the key 'lazy' in the Babel configuration must be a boolean".

I don't think it's much clearer than what I have here, but I do think we could do better in general with work focused on making the error messages give better feedback.

That reminds my that I still have a PR to add code frames to configuration issues. I can continue my work, what do you think?

Not sure I follow. What code frames could we show for this case? Do you mean showing information about the config file itself?

danez · 2017-12-02T11:30:40Z

packages/babel-plugin-transform-modules-commonjs/src/index.js

@@ -132,14 +143,26 @@ export default function(api, options) {

            let header;
            if (isSideEffectImport(metadata)) {
+              if (metadata.lazy) throw new Error("Assertion failure");


I guess this should never really happen, but maybe we could make the error a little bit more descriptive?

For assertions I don't usually bother. I'd just assert(!metadata.lazy) but usually that isn't enough to make Flowtype happy so I've kind of got into the habit of doing it like this. I really just threw this in for us.

danez · 2017-12-02T11:44:55Z

packages/babel-plugin-transform-modules-commonjs/README.md

+  Local paths are much more likely to have circular dependencies, which may break if loaded lazily,
+  so they are not lazy by default, whereas dependencies between independent modules are rarely cyclical.
+
+* `Array<string>` - Lazy-initialize all imports with source matching one of the given strings.


do we need Array<string>, do you think it is a common case? I guess boolean | (string) => boolean would capture this case too. I was also thinking about more cases like "enable really everything" or "enable everything with a blacklist", but that can all be handled with the callback.

The disadvantage of the callback is that it forces the user to use .babelrc.js instead of .babelrc

Yeah the .babelrc/package.json#babel case was the reason I added the array. Seems like a whitelist was easy enough to support that I'd just throw it in.

nicolo-ribaudo · 2017-12-02T12:07:02Z

packages/babel-helper-module-transforms/src/normalize-and-load-metadata.js

+      } else if (typeof lazy === "function") {
+        metadata.lazy = lazy(source);
+      } else {
+        throw new Error(`'lazy' must be a boolean, string array, or function`);


Here it shold throw the same message as https://github.com/babel/babel/pull/6952/files#diff-71f62b3225be3bae0ddc0c8e49189aa7R29

Actualy, can this error be thrown? It should already be thrown there.

One throws up front when you declare the plugin, which seemed like it would be best for users, this one throws inside the transform itself in case someone else decides to use helper-module-transforms and calls it wrong. I can make the errors the same though, that's true.

xtuc

Awesome, that's really nice!

xtuc · 2017-12-02T12:38:03Z

packages/babel-plugin-transform-modules-commonjs/src/index.js

+    typeof lazy !== "function" &&
+    (!Array.isArray(lazy) || !lazy.every(item => typeof item === "string"))
+  ) {
+    throw new Error(`.lazy must be a boolean, array of strings, or a function`);


It's because it's a key in the configuration.

zertosh · 2017-12-03T01:48:32Z

Super cool! Question, why did you decide to go with always calling the memoized require rather than conditionally getting the previously stored require value? For compat with modules whose value is falsey ? If always calling the memoized require's perf is on-par or better then I'll deprecate babel-plugin-transform-inline-imports-commonjs

loganfsmyth · 2017-12-03T02:16:40Z

@zertosh I honestly didn't think on it too much. If anyone wants to do some benchmarks to compare, and your approach of having a separate variable is noticeably faster, we can certainly do it. I went this route because it seemed like it'd be easier for people debugging code to just have a single name to reference, and because it seemed like this approach would be pretty easy for engines to inline, since the function never changes and is statically guaranteed to always return the same value.

nicolo-ribaudo

Really nice feature 🚀

jamesreggio · 2018-02-19T17:24:44Z

@zertosh @loganfsmyth — I did some empirical benchmarking of both in my React Native app and witnessed the new lazy option to be 24% faster than babel-plugin-transform-inline-imports-commonjs (with a variance of 5%).

It's possible that other changes in the Babel 7 version of the mainline commonjs plugin are to account for these improvements, but I'd say — from my limited perspective — that it's safe to sunset babel-plugin-transform-inline-imports-commonjs.

Thank you both for this feature. It's made a huge improvement in my cold-start time.

(Addendum: if anybody would like to try using babel-plugin-transform-inline-imports-commonjs with Babel 7, pull my branch here.)

loganfsmyth · 2018-02-19T17:31:28Z

@jamesreggio Happy to hear it. Beware there's one known bug: #7176

zertosh · 2018-02-19T23:11:30Z

@jamesreggio, interesting - I expected some difference one-way or the other, but not that stark. Curious to see this is a way I can repro (just for my know education). I'll deprecate babel-plugin-transform-inline-imports-commonjs as soon as Babel 7.0 is stable.

jamesreggio · 2018-02-20T00:01:41Z

@zertosh — I was surprised too. I thought your use of a local variable would be more performant. I wish I could supply a repro to you, but I'm measuring real-user scenarios in our closed-source app, and I don't have time to build a separate benchmark suite.

hzoo added PR: New Feature 🚀 A type of pull request used for our changelog categories area: modules labels Dec 2, 2017

danez reviewed Dec 2, 2017

View reviewed changes

nicolo-ribaudo reviewed Dec 2, 2017

View reviewed changes

xtuc reviewed Dec 2, 2017

View reviewed changes

nicolo-ribaudo approved these changes Dec 17, 2017

View reviewed changes

loganfsmyth added 2 commits December 17, 2017 18:33

Consistently return AST nodes.

b900a3e

Expose a 'lazy' option for the CommonJS transform.

53826aa

loganfsmyth force-pushed the commonjs-lazy branch from 76763fa to 53826aa Compare December 18, 2017 03:18

loganfsmyth merged commit 44ea943 into babel:master Dec 18, 2017

loganfsmyth deleted the commonjs-lazy branch December 18, 2017 03:32

jamesreggio mentioned this pull request Feb 19, 2018

WIP: Support Babel 7 zertosh/babel-plugin-transform-inline-imports-commonjs#11

Closed

loganfsmyth mentioned this pull request Feb 19, 2018

'lazy: true' on commonjs transform fails when namespace and named both in use #7176

Closed

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a 'lazy' options to modules-commonjs #6952

Add a 'lazy' options to modules-commonjs #6952

loganfsmyth commented Dec 1, 2017

babel-bot commented Dec 1, 2017 •

edited

Loading

danez Dec 2, 2017

xtuc Dec 2, 2017

loganfsmyth Dec 2, 2017

xtuc Dec 2, 2017

loganfsmyth Dec 18, 2017

danez Dec 2, 2017

loganfsmyth Dec 2, 2017

danez Dec 2, 2017 •

edited

Loading

nicolo-ribaudo Dec 2, 2017

loganfsmyth Dec 2, 2017

nicolo-ribaudo Dec 2, 2017 •

edited

Loading

nicolo-ribaudo Dec 2, 2017 •

edited

Loading

loganfsmyth Dec 2, 2017

xtuc left a comment

xtuc Dec 2, 2017

zertosh commented Dec 3, 2017

loganfsmyth commented Dec 3, 2017

nicolo-ribaudo left a comment

jamesreggio commented Feb 19, 2018 •

edited

Loading

loganfsmyth commented Feb 19, 2018

zertosh commented Feb 19, 2018

jamesreggio commented Feb 20, 2018

Add a 'lazy' options to modules-commonjs #6952

Add a 'lazy' options to modules-commonjs #6952

Conversation

loganfsmyth commented Dec 1, 2017

babel-bot commented Dec 1, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danez Dec 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolo-ribaudo Dec 2, 2017 • edited Loading

Choose a reason for hiding this comment

nicolo-ribaudo Dec 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xtuc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zertosh commented Dec 3, 2017

loganfsmyth commented Dec 3, 2017

nicolo-ribaudo left a comment

Choose a reason for hiding this comment

jamesreggio commented Feb 19, 2018 • edited Loading

loganfsmyth commented Feb 19, 2018

zertosh commented Feb 19, 2018

jamesreggio commented Feb 20, 2018

babel-bot commented Dec 1, 2017 •

edited

Loading

danez Dec 2, 2017 •

edited

Loading

nicolo-ribaudo Dec 2, 2017 •

edited

Loading

nicolo-ribaudo Dec 2, 2017 •

edited

Loading

jamesreggio commented Feb 19, 2018 •

edited

Loading