Add option to code split dynamic imports in bundles

[jimsimon]

I suspect this is probably out of scope given Deno appears to be only targeting server runtimes where this matters less, but it would be great for web usage if Deno's bundle command had an option to code split for dynamic imports. Without this feature, we'll likely see a webpack equivalent for Deno. It would be unfortunate to have separate bundlers for targeting server vs web. Additionally, servers can benefit from faster startup times if dynamic imports were code split.

[kitsonk]

deno bundle would unlikely ever include something like this. For Deno.bundle() that might be a different story, but what would your expectations be? Every dynamic import is broken out to a seperate chunk? Ultimately even Deno.bundle() isn't the best for general purpose bundling for a browser. I am afraid there will always be seperate bundlers for targeting server vs. the web, because they have quite different concerns.

[mischkl]

I'd imagine this is actually quite relevant for the server use case as well, not for "applications" but for reusable libraries. Beyond a certain library size it's pretty common practice to split it up into sub-modules, some of which may indeed still depend on each other, but with the difference that the consumer of the library has the option to only import the sub-modules he needs. This is IMHO an important feature for publishing libraries, if you want to truly avoid the need for additional build tooling.

It wouldn't have to be limited to dynamic imports, of course - just like with webpack it should be possible to specify multiple entry points as a list of files.

[kitsonk]

@mischkl there is nothing preventing someone from creating deno bundle on various entry points at the moment and then having a server script the imports multiple bundles.

I can see the point about potentially not bundling bundles, and simply leaving them as an external import, as well as supporting a more complex dependency analysis so that deno bundle a.ts b.ts c.ts would ensure that if a.ts depended on b.ts that it imported the bundle of b.ts instead of inlining b.ts and its dependencies again. Getting more complex than that would be potentially an enhancement for Deno.bundle().

[jimsimon]

I think enhancing the compiler api for Deno.bundle() would be a great way to approach this. That keeps the deno bundle cli command that same but would also allow for more tools to be built on top of the bundle logic. This combined with the concepts being discussed about exposing typescript transformers (#3354) could potentially allow for the creation of something akin to webpack that's built on top of Deno's core tooling.

My expectations would be that Deno.bundle() can do the advanced dependency analysis you mentioned, including splitting out multiple vendor chunks much like webpack can. The general idea in my mind is that we want to load as little code as needed whether we're on a server or on the web. The bundle logic right now forces us to load and parse everything even if we're only going to use one small code path. This is fine for smaller scripts and web apps but starts to have a real performance impact once on larger projects. Server cold start time is definitely a concern with the current bundle logic (though I'll be honest that my personal focus is on web frontends).

[kitsonk]

@jimsimon take a look at #4752. From your perspective of your use case, how would you expect the API to look (please comment in that issue).

[kitsonk]

As of 1.5, dynamic imports are no longer inlined under any conditions and bundles are simply ESM files, so they become really difficult to detect as a unique file. So effectively it is up to the end user to figure out if they want to import a bundle (and get further bundling) or use dynamic import() and have that lazily loaded at runtime.