Code splitting for Deno.emit() or deno bundle

[aegooby]

I am trying to use Deno to write a full stack web application and one of the things that feels missing to me is the lack of ability of the Deno.emit() or the CLI bundler to do any code splitting using dynamic imports. This results in huge bundle sizes for end users making the experience not that great. I believe this also has ramifications for servers too where cold start times are increased highly by having these huge bundles.

It would be nice if in a similar way to Webpack/Parcel that the Deno.emit() functionality could resolve these dynamic imports and create separate bundle files for them and map these imports to the corresponding bundles in the entry point bundle file. Right now as a workaround I have to run multiple deno bundle/Deno.emit(), and the imports in my TypeScript code look like,

const something = await import("./something.bundle.js");

which is far from ideal.

[kitsonk]

It is something we might consider for Deno.emit() but unlikely to be considered for deno bundle as it is intended to be straight forward and low config.

[ebebbington]

It is something we might consider for Deno.emit() but unlikely to be considered for deno bundle as it is intended to be straight forward and low config.

I have proposed Deno to bundle the client side TS at my workplace, but do this, I doubt they will go for it (and I probably wouldn't either), which I feel is a huge downside

Ideally I feel we should be able to (somehow) bundle all files in a dir, and place it in a mirrored dir, eg

deno bundle client/js public/js

So thee bundled code isn't inside a single js file, meaning we wouldn't have to setup any kind of routing (because we could still do <script src="/public/js/users/new.js"></script>)

[agorushkin]

Just a follow-up since it's been awhile since the last update.

Has splitting been put off? Obviously the issue isn't closed, so I'm assuming it's still in the plans.
If I'm correct about the latter, have you got any estimates? Thanks in advance.