Closure-compiler: [FEATURE] Support dynamic import

[dtruffaut]

Support dynamic import :

https://developers.google.com/web/updates/2017/11/dynamic-import

module.js :

export const foo = _ => {
  console.log('foo');
}

main.js :

const main = async _ => {

  const m = await import('module.js');
  m.foo();

  (await import('module.js')).foo();

}

main();

Should display :

foo

The thing is about supporting 'export' and 'import' keywords.

[blickly]

Thanks for filing the tracking bug.

Just want to confirm that the feature we're tracking here should be the currently stage 3 dynamic import syntax, not top-level await syntax.

[dtruffaut]

Yes !

[ChadKillingsworth]

@blickly There is already both Chrome and Safari support for this feature. The hard part is figuring out exactly what the compiler should do here. But parsing would be a good first step...

[dtruffaut]

Any news on this ?
At least, just allow the parsing ?

[MaxMilton]

Would be amazing to see parser support for import().

Spent the morning trying to add Closure Compiler as the minifier in https://github.com/MaxMilton/sapper-template-rollup/tree/feat/use-closure-compiler but in the end it turns out the import() can't be parsed and the compiler bails completely. In this project the import function is polyfilled so we don't need the compiler to do anything special. This is now a blocker for adding Closure Compiler support :sweat:

[lauraharker]

Created Google internal issue http://b/122961838 for this request.

[Tonsil]

Has there been any movement on this recently? Asking because we're getting into a project for which it would be extremely useful. I figured I'd ask before we decide to fork and fix it ourselves.

[dtruffaut]

Most of JS developers now use Rollup instead of Closure Compiler.

Rollup does a great job in handling await import instructions and moving all your imports at the same level on the disk.

As a result, code splitting leads to faster load times.

File size matters, but code splitting really is on another level. The benefits are impressive.

In addition, Rollup understands ESNext and respects property names, which leads to fewer bugs.

As of July 2019, I would recommend Rollup over Closure Compiler.

[MaxMilton]

Although rollup and closure compiler do have some overlap in that they can both handle JS bundling, their functionality is _not_ mutually exclusive. If you use rollup you can also use closure compiler with a plugin like @ampproject/rollup-plugin-closure-compiler.

Rollup is an excelent module bundler and closure compiler is an excelent JS minifier. If you want the most performant code, why not use both?

[rjakobsson]

@Tonsil, did you fork?

[Tonsil]

@Tonsil, did you fork?

No, we punted on it. We wanted to dynamically import a library because it's on the large side and not needed in all cases. For now, we decided instead to keep that code as a separate file (for other reasons, like not wanting to have to rewrite it just yet). Our workaround was to have our modular code write out a script tag on the page and pull it in that way. If/when we do decide to fork, I'll let you know.

[brad4d]

"Support" can mean at least 2 different things for dynamic import here.

1. Pass a dynamic import call from the source all the way through so it's still there in the compiled version, in order to load some ES module that isn't part of the JS we're compiling.
2. Recognize that a dynamic import statement is referring to another file that is being compiled and do some kind of magic code-splitting based on this to break the output into multiple chunks that dynamically load each other as needed.

People building big applications definitely want the code splitting, but there's a lot to work out there.

I'd really like to know how much people care about importing foreign ES modules (number 1).
closure-compiler doesn't support doing that even with static import now.
Do people care, or does that not matter because everyone wants to compile all parts of their application together at once anyway?

I would like to advocate for implementing import of foreign ES modules, but that will be a hard sell if I cannot show that a significant number of people really want it and would benefit from it.

[sjrd]

I'd really like to know how much people care about importing foreign ES modules (number 1). closure-compiler doesn't support doing that even with static import now. Do people care, or does that not matter because everyone wants to compile all parts of their application together at once anyway?

FWIW, the Scala.js compiler cares, and therefore, indirectly, a lot of Scala.js users. That's because Scala.js uses Closure to optimize the Scala.js code but not its potential JS dependencies.

[brad4d]

I also have this related question:

Do people want closure-compiler to be able to generate output that functions as an ES module and can be imported JS code the compiler never sees?

[sjrd]

Yes. Scala.js would also like that. I'd love to be able to remove this line of code:
https://github.com/scala-js/scala-js/blob/da1627b4715c4059c742c511ac02a285174b36c6/linker/jvm/src/main/scala/org/scalajs/linker/backend/closure/ClosureLinkerBackend.scala#L50

[adrianholovaty]

@brad4d wrote:

"Support" can mean at least 2 different things for dynamic import here.

1. Pass a dynamic import call from the source all the way through so it's still there in the compiled version, in order to load some ES module that isn't part of the JS we're compiling.

2. Recognize that a dynamic import statement is referring to another file that is being compiled and do some kind of magic code-splitting based on this to break the output into multiple chunks that dynamically load each other as needed.

People building big applications definitely want the code splitting, but there's a lot to work out there.

I'd really like to know how much people care about importing foreign ES modules (number 1).
closure-compiler doesn't support doing that even with static import now.
Do people care, or does that not matter because everyone wants to compile all parts of their application together at once anyway?

My two cents (as a longtime Closure Compiler user, and somebody who would like it to support dynamic module import): Number 2 is much more important. I wouldn't personally need to dynamically load JS that's not being compiled by my own workflow.

[tmb-github]

@MaxMilton A brute-force workaround for including dynamic import() in JavaScript to be compiled with the Closure Compiler is temporarily to rename every import() statement to dynamicImport() and then compile, then convert every dynamicImport() back to import() in the resulting compilation. This is admittedly incredibly dreadful, but IT WORKS (at least in my experiments with "SIMPLE OPTIMIZATIONS"). The compiler leaves dynamicImport() as-is (i.e., unrenamed), and so you can search-for and replace it. (Yes, this is not an ideal solution, but it works in my tests. See what you get.)

[stevendwood]

erm, you could also just wrap the dynamic import if you have control over all the code you are building like Function("return import('" + moduleName + "')")() not very attractive either but works.

[ChadKillingsworth]

Design document for support:
https://docs.google.com/document/d/1thSbGV5i96jltVwn76KYrPkWoNc-yj_KU3HtBGUCgMc/edit