Skip to content
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

Remove 'deno bundle' #10

Open
lucacasonato opened this issue Feb 3, 2020 · 2 comments
Open

Remove 'deno bundle' #10

lucacasonato opened this issue Feb 3, 2020 · 2 comments
Assignees
Labels
feat A new feature

Comments

@lucacasonato
Copy link
Owner

Instead of bundling the application using deno bundle before deployment it should just be precompiled with deno fetch and then use .deno_dir for dependencies.

@lucacasonato lucacasonato added the feat A new feature label Feb 3, 2020
@lucacasonato lucacasonato self-assigned this Feb 8, 2020
@lucacasonato
Copy link
Owner Author

I have been looking into this, and in my testing it seems that - as expected - lambdas with bundles are definitely a lot smaller than when using non bundled applications. Non bundled applications have to add source code and compiled code into the lambda, effectively doubling code size. The .deno_dir also adds .map and .meta files which also add to the total lambda size. In addition to this, all project code has to be added to the bundle because it is hard to determine what files will be used by the program as there is no clean programmatic way of getting the dep tree of a file in deno right now. deno bundle sort of has 'file level tree shaking' which defo helps to reduce lambda size.

Right now the only reason I see where non bundled code with a .deno_dir is better, would be in the case of:

  • dynamic imports (those are pretty rare in backend code)
  • wasm (or is this bundled?)
  • plugins

What do you think?

@wesleycoder
Copy link
Contributor

wesleycoder commented Feb 9, 2020

I think that we can continue with deno bundle for now since it is preferrable to have the smaller size and avoid adding this complexity with selecting the right files.
Maybe we should wait until a valid use case arrives and think of it with more context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat A new feature
Projects
None yet
Development

No branches or pull requests

2 participants