3 ms·

I'm doing server code (which I guess is the main use case for nodejs), I just COPY the project folder in the docker and ship that. No need for bundling, shaking

by forty 2y ago

I'm doing server code (which I guess is the main use case for nodejs), I just COPY the project folder in the docker and ship that. No need for bundling, shaking and other annoyance.

9dev 2y ago
You'd likely still benefit from using TypeScript and transpiling that to plain JavaScript (preventing a lot of subtle bugs), and tree shaking to minimize your Docker image size (yielding faster deployments).
- forty 2y ago
  We do use TS already. And yeah sure, we could save a second or two on our deployment, but I'm not sure that's worth the mess
  - 9dev 2y ago
    In case you ever get to that point; have a look at Unbuild (https://github.com/unjs/unbuild https://github.com/unjs/unbuild). It's what Vite uses for their own builds, and really painless to set up.
    - forty 2y ago
      Haha I'm probably getting too old or something but I really cannot see what this tool does exactly and why I'd need it. I have been working on what is now a fairly large typescript/nodejs monorepo (over 1M LoC) for the past ~13 years, and we can simply build it all with tsc -b, and COPY it in the docker image as I said, it's nice and simple and works great.
WorldMaker 2y ago
Tree-shaking also happens in GC heap space (both in the server and in the browser): V8 and SpiderMonkey and JavaScriptCore will all eventually treeshake unused code out of memory entirely. The ESM format was designed to allow that. Modules actually only reference each other through weak references and things like import * build proxy objects of weak references designed for tree-shaking. Depending on how your application is structured, an ESM version of a server-only Node application may still benefit from the performance optimizations of the server being able to do dead code elimination at runtime.
selfmodruntime 2y ago
Yeah, there is no point in tree shaking and bundling for server code so your comment makes little sense.

by forty 2y ago

I'm doing server code (which I guess is the main use case for nodejs), I just COPY the project folder in the docker and ship that. No need for bundling, shaking and other annoyance.

9dev 2y ago

You'd likely still benefit from using TypeScript and transpiling that to plain JavaScript (preventing a lot of subtle bugs), and tree shaking to minimize your Docker image size (yielding faster deployments).

forty 2y ago
We do use TS already. And yeah sure, we could save a second or two on our deployment, but I'm not sure that's worth the mess
- 9dev 2y ago
  In case you ever get to that point; have a look at Unbuild (https://github.com/unjs/unbuild https://github.com/unjs/unbuild). It's what Vite uses for their own builds, and really painless to set up.
  - forty 2y ago
    Haha I'm probably getting too old or something but I really cannot see what this tool does exactly and why I'd need it. I have been working on what is now a fairly large typescript/nodejs monorepo (over 1M LoC) for the past ~13 years, and we can simply build it all with tsc -b, and COPY it in the docker image as I said, it's nice and simple and works great.

WorldMaker 2y ago

Tree-shaking also happens in GC heap space (both in the server and in the browser): V8 and SpiderMonkey and JavaScriptCore will all eventually treeshake unused code out of memory entirely. The ESM format was designed to allow that. Modules actually only reference each other through weak references and things like import * build proxy objects of weak references designed for tree-shaking. Depending on how your application is structured, an ESM version of a server-only Node application may still benefit from the performance optimizations of the server being able to do dead code elimination at runtime.

selfmodruntime 2y ago

Yeah, there is no point in tree shaking and bundling for server code so your comment makes little sense.