How are code changes affecting the size of the Deno binary?

scarf on the Deno Discord had this question:

Are there any guides to building a 'stripped-down' version of deno from source? for example, i'd like to build a deno binary that runs typescript files but other additional features like check, fmt, jupyter, lsp removed. this would be useful to reduce binary size in docker container

I figured the addition of Jupyter code was pretty small (main new requirement is zeromq, the rest is all protocols that Jupyter handles). To test that hypothesis, I calculated the Deno size between Linux canaries from dl.deno.land.

Methodology

• Pull the last N commits via GitHub's GraphQL API

• Perform a HEAD against the canary linux asset URL to get the size

• If a commit download isn't found, skip it

Conclusion

The Jupyter additions don't appear to have added much to the size, relative to the overall size of the binary. More investigation is needed to determine how much LSP and Chrome Devtools add to the binary. However, these development tools are not part of running a standalone server. The Jupyter bits for instance are only executed if and when deno jupyter is invoked. The same goes for REPL and LSP bits.

Then again, if someone really has the desire to maintain a whole 'nother copy of Deno you can:

• Roll your own runtime

• Deploy with Deno Deploy

Happy Hacking!