Deno compile optimization
Hi Everyone,
I'm building a CLI tool with Deno and I was wondering
- if there are any optimizations I can make for the compiled file size,
- how much of the build in terms of KB is the runtime
- how much of the build is std lib and if there's any tree-shaking on the build
- If there are future compile enhancements in the pipeline
Thanks for all the work you do
3 Replies
Hello! Great to hear you're building a CLI tool with Deno. Let's address your questions one by one based on the documentation:
1. Optimizations for the compiled file size: The documentation mentions that you can use the
--lite flag when compiling your application with deno compile. This flag tells deno compile to use a slimmed-down runtime-only Deno binary instead of the full Deno binary that was used previously, which can result in binaries that are 40-60% smaller than those generated by Deno 1.6. 🦕
2. Size of the runtime in the build: The documentation doesn't provide an exact number of kilobytes for the runtime size within the build. However, it does mention that using the --lite flag can significantly reduce the output size, which implies that the runtime does contribute a notable amount to the overall size.
3. Size of the std lib and tree-shaking: The documentation does not explicitly mention the size of the standard library in the build or whether tree-shaking is performed. However, it does suggest that unnecessary code is included in the binary and that there is potential to reduce the final binary size by around 60% by stripping out this code. This indicates that there may be some form of optimization, but it's not clear if it's specifically tree-shaking.
4. Future compile enhancements: The documentation does indicate that there are plans to improve deno compile, including minimizing the total binary size, which is a work in progress. This suggests that future enhancements to the compile process are indeed in the pipeline.
Keep an eye on the official Deno release notes and blog posts for updates on new features and improvements to the deno compile command. The Deno team is continuously working on making the tooling better, andyour feedback is always valuable to guide their development efforts. 🦕
Compiled deno binary is basically just the regular deno binary with your code embedded inside it. Deno binary size varies by platform, and not sure about exact numbers, IIRC it's around 70mb. Unless your own code has huge dependencies, it's likely the runtime size is order(s) of magnitude bigger than the embedded JS/TS.
There has been recent work to introduce a minimized
denort binary for purposes of deno compile. That has much of the built in development tooling of normal deno binary stripped away. Not sure about exact numbers, IIRC the lighter compiled runtime might be somewhere around 50mb. Also not sure whether that feature is released yet, as it's very recent! If/when that is released, I think deno compile should use the lightweight runtime by default, so you'll automatically see smaller binaries without any extra configuration on your part.
Deno has no tree-shaking in the traditional sense. Your code is effectively "tree-shaken" before even loaded; that's the nature of the module graph which traverses all your modules and recursively imports only what is needed starting from your entry point. That kind of makes treeshaking mostly irrelevant, or unneeded. That is, if and only if your code and your dependencies are handling subdependencies using best practices, like using url imports so that you import only what you need (using single function imports instead of importing mod.ts for example). Depends on the quality of the libraries you use, how effective this "tree shaking" is.
If you use a lot of npm: imports, chances are they import a lot of unneeded sub-dependecies that can not be "tree shaken" very effectively by Deno. (that's why Node/NPM has all kinds of tools for tree-shaking after-the fact, AFAIK)
AFAIK, none of the STD library is included into compiled binaries, unless you explicitly import them in your own code. Even then, only those parts you actually use are included, so no "tree-shaking" should be necessary.