Wanted: bundler about deno_std HOT 10 CLOSED

I suspect we would be better off adopting something like: https://github.com/electron/asar if we went down the virtual file system route. It isn't a bad idea at all, and like Electron apps, .asars could be built into a single binary distribution.

from deno_std.

@keroxp

Given an arbitrary set of modules, authored in TypeScript, using imports with include fully qualified URLs (inlcuding the extension) output a single .ts file which can then be used with Deno (possibly a single JS file).

The use case would be something like, as a developer, I want to create a single file asset that I can potentially distribute which contains all of my dependencies for a Deno application, without subsequent fetches of modules. I can also be sure that I have fixed versions of the remote modules which I can have tested and ensured the correct behaviour.

It should output either to the stdout, so it can be redirected to a file (which is best as a first step) and then eventually output to a file via a flag.

It is unlikely we would be able to replace rollup with this as part of the build process, as we are dependent upon a lot of plugins and other features of rollup to transform some of the code which would not be required by a Deno bundler. We have a long path until Deno can build its own JavaScript runtime, and I am not sure it is worth the effort for a long time.

from deno_std.

Is there a reason to make this bundle to a TS file? Why not support tar or zip archives? This way, everything works the same way it would for unbundled files, and decisions about processing and combining can be left out of it. Each archive just becomes its own virtual file system root (or directory - think Linux mounting an image at a mount point), and all resolutions behave accordingly.

This could even extend to url imports using hash to denote paths within a remote archive (e.g. https://foo.com/archive.tar#/sub/dir or file://./archive.tar#/sub/dir)

PS - I think we should use the extension ".tzar" 😆

from deno_std.

I don't fully understand what you want. What is the main purpose of the bundler?

• bundle what?
• when used?
• who uses?
• place on where?

Are you simply planning to replace rollup on deno core?

from deno_std.

This rollup plugin can resolve URL imports: https://github.com/thgh/rollup-plugin-url-import

from deno_std.

@thgh the module resolution isn't the issue, it needs to run under Deno.

from deno_std.

Proof of concept:

deno https://raw.githubusercontent.com/thgh/deno-rollup/master/cli.js input.js

from deno_std.

@thgh That example may not be able to bundle .ts file. I got:

Uncaught Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)

from deno_std.

After some struggling with typescript and rollup-plugin-typescript and this particular file, here is a version that supports typescript:

#examples
deno --allow-net https://unpkg.com/[email protected]/cli.js https://raw.githubusercontent.com/denoland/deno_std/master/prettier/main.ts -T  > prettier.js
deno --allow-net https://unpkg.com/[email protected]/cli.js https://raw.githubusercontent.com/denoland/deno_std/master/http/file_server_test.ts -d dist
deno --allow-net https://unpkg.com/[email protected]/cli.js -o logger_test.js -i https://raw.githubusercontent.com/denoland/deno_std/master/log/logger_test.ts

I'm not 100% sure if my implementation of the deno module resolution #233 is an exact match.

from deno_std.

Moving this discussion back to the main repo, as some time as passed: denoland/deno#2357

from deno_std.