"deno bundle" to produce a dependency-less single file version of a module

[ry]

Using TypeScript's outFile feature. Should support multiple targets.

[kitsonk]

Duplicate of #21 😁

[kitsonk]

Which was moved to denoland/std#116 😁

[kitsonk]

Also, you can't just use --outFile with ESM. ESM modules can't just be concatenated, they have to be parsed and rewritten to be able to exist in a single script file that can be loaded. One of the big disadvantages of ESM over AMD (which allows concatenation without rewriting).

So we would either need to implement a special syntax structure for Deno that informed Deno how to load each module, or we would have to parse each module, rewrite its own closure, and rewrite all the imports (e.g. rollup).

[ry]

@kitsonk I think the target should be AMD. The use case here is deploying to browsers. (I think deno should also be able to load AMD?)

[kitsonk]

Oh, good point. Changing the output target and generating a bundle. Hadn't occurred to me, forrest for the trees problem.

We would need to build an AMD loader into Deno, which we used to have before we switched to ESM. It could just be written into the start of a bundle, or built into the runtime.

[ry]

We would need to build an AMD loader into Deno, which we used to have before we switched to ESM. It could just be written into the start of a bundle, or built into the runtime.

Better to write at the start of bundle so it's completely hermetic.

[pkuhlmann]

amd is dead old let it die

[kitsonk]

@pkuhlmann so what is your suggestion then. Just stating something is "dead" isn't very useful.

[thgh]

What is the usecase precisely?

[ry]

What is the usecase precisely?

To make bundles for websites.

[kitsonk]

To make bundles for websites.

Or any workload where you want to resolve all the the external runtime code into a single artefact, one that could be independently versioned and managed easily in a source control system which is easily audit-able with industry standard tooling.

It would be the foundation for building custom snapshots. While not a strict requisite for that, it certainly would make doing it easier. Currently we use rollup to generate a bundle which then get loaded into the snapshotter for the internal compiler and runtime, but for end users as well as for ourselves potentially, we need a better way to have a single artefact we can load to generate the snapshot.

[thgh]

Okay, what's the blocking issue with rollup then?
Is it because rollup is running on Node?

[JustFly1984]

Hello everyone, I want to add my two cents, concerning browser builds, there definitely should be a code splitting implemented natively and lazy-loading too.

[kitsonk]

Those are not important features for Deno. If someone was building for the web, they wouldn't want to use a built in Deno bundler.

[JustFly1984]

What if Deno evolves and will be integrated to v8 and other browsers as native TS?

[kitsonk]

That doesn't make sense at all for Deno. Deno incorporates V8. V8 won't incorporate Deno.

Even then you solve for the problems you have, not the problems you don't.

[JustFly1984]

Code splitting could be useful for lambda functions, to lower the main module bundle size, by lazy-loading some corner case code paths. Currently with node.js execution at AWS for example, we need to monitor a file size, and split lambdas to manage cold start time.

[i5ar]

Node.js bundlers do not work well with ES modules (e.g. parcel-bundler/parcel#1401) since they were not conceived with ES modules in mind. Many front-end developers only use Node.js to bundle the app and they will definitely make the switch if Deno come out with a better tool.

[kitsonk]

Just to update those following this thread, I have raised two PRs, one built into Deno to generate a bundle and one in deno_std to allow the loading of the bundle. The bundle will consist of all the statically identifiable dependencies for the root module, output to a single file. The file is a concatenation of each module transpiled to AMD.

With the PRs, usage would look something like this:

$ deno bundle https://deno.land/x/oak/examples/server.ts oak_server.js
[43/43] Downloading https://raw.githubusercontent.com/oakserver/oak/master/pathToRegExp.ts
Bundling "https://deno.land/x/oak/examples/server.ts"...
Emitting bundle to "oak_server.js"...
897.2 kB emitted.
$ deno -A https://deno.land/std/bundle/run.ts oak_server.js
[1/1] Compiling https://deno.land/std/bundle/utils.ts
Start listening on 127.0.0.1:8000

[wongjiahau]

Those are not important features for Deno. If someone was building for the web, they wouldn't want to use a built in Deno bundler.

By the way, I am using it to bundle a website, if not why alternatives should I use that dont depend on any Node or npm related modules?

[kitsonk]

@wongjiahau that is the intention of the compiler APIs: https://deno.land/manual/runtime/compiler_apis#denobundle