-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wanted: bundler #116
Comments
I don't fully understand what you want. What is the main purpose of the bundler?
Are you simply planning to replace |
Given an arbitrary set of modules, authored in TypeScript, using imports with include fully qualified URLs (inlcuding the extension) output a single 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. |
This rollup plugin can resolve URL imports: https://github.com/thgh/rollup-plugin-url-import |
@thgh the module resolution isn't the issue, it needs to run under Deno. |
Proof of concept:
|
@thgh That example may not be able to bundle
|
After some struggling with
I'm not 100% sure if my implementation of the deno module resolution #233 is an exact match. |
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" 😆 |
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, |
Moving this discussion back to the main repo, as some time as passed: denoland/deno#2357 |
Very simple to start - but something like rollup - that uses deno-like imports.
Please scope out ideas here before submitting PR - this is ideally something everyone can share.
The text was updated successfully, but these errors were encountered: