You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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)
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.
Instead of bundling the application using
deno bundle
before deployment it should just be precompiled withdeno fetch
and then use .deno_dir for dependencies.The text was updated successfully, but these errors were encountered: