Code splitting on import("...")

[willstott101]

Enhancement

Webpack (and other bundlers) support automatic code splitting on import() statements. This can be especially useful for large libraries with lots of code which is only used when performing certain tasks (an example might be drag and drop folder support, also accepting different archive formats like zip/tar, I could avoid loading a js implementation of various compression algorithms unless they're actually needed).

Currently dojo will bundle the code imported by the import() statement within the main bundle.

Only supporting code-splitting by app routes seems overly restrictive to me, and the bundles key feels like a leaking of concerns to config (and especially brittle).

Package Version: 6.0.3

I presume the current behaviour comes from this function.

• Do you think it would be possible to modify cli-build-app to support automatic code splitting in more cases?
• Would you agree it's useful and accept a PR to implement this?

[matt-gadd]

The build tool should support import() statements, because the mechanisms we use under the hood for all of our lazy loading mechanisms leverage it.

In terms of bundling by configuration, we strongly believe it's better to decouple bundling semantics from code, and this was a pattern used in the dojo 1 build tool to good effect. It provides numerous advantages:

• You can see how an entire app is bundled in one central configuration rather than across many call sites across many modules
• No code is required to be changed to add/move/remove bundles
• You can configure "bundles" of modules in one place to a name, where the alternative would be to do this at every call site you do an import. You can even use globs to do this, this is very useful in everyday examples like: Support minimatch/globs for matching bundles #250
• The declarative nature allows us to do additional abstractions on top of this (for example in the future deciding your critical bundle splitting path for you), without touching your code.

In general we try and also abstract away the sync/async nature of this loading too, for example for widgets themselves a user can just use a normal import in their code and they do not have to deal with the async nature of the return of an import() at all.

I'm going to close this as working as designed given how the issue is currently written. If their is a bug with a specific scenario of import() please do raise that and we would definitely accept a fix 👍.

[willstott101]

Thank you very much for the input.

import() statements do indeed cause a bundle split provided your tsconfig.json is not set to something which poly-fills them (you want at least "module": "es6").

I missed this as I forgot tsc in a depending project will effectively re-transpile dependencies with it's own module settings, and I had already got the settings correct in the dependency.

I might have a look at updating the dojo docs to reflect that code splitting can be achieved using import() as well as routes and bundles.

The only remaining confusion is that import(...) statements in app-level code are given named bundles e.g. node_modules/electron/electron.d.ce068c306ed4c451c5b1.bundle.js but bundles split from import() statements in dependencies have a numbered bundle 0.61f4f5a67b09fe2fec91.bundle.js.

I don't yet know what's causing this, but frankly it's not currently bothering me much.