🧼 optimize install size

[natemoo-re]

Reduces npm install size by 63% (723kB → 268kB unpacked) via:

• optimizing clang build flags with explicit exports and dead code elimination
• stripped source maps and src/ duplication from the npm package

Also bumps minimum node version to v22 (current LTS).

Future optimization opportunities identified (with unknown performance impact) include:

• switching from -02 to -0z, adding wasm-opt step
• compress wasm text (testing showed brotli + z85 encoding to be largest byte reduction)
• strip data that can be extrapolated from wcwidth

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/clayterm@35

commit: 79052b0

[dreyfus92]

overall looks really good. since you're optimizing install size, are you planning on the near future to add a "no size regression test", cause rn there's nothing in the CI that asserts the package stays under a certain size. without that the size could quietly creep back up over time.

[cowboyd]

There are a couple of optimizations here; some of which I'm 100% cool with, the others I think we need to make sure we do intentionally.

Unalloyed Wins:

• The linker changes to only export the functions we need and to gc/strip the rest. I don't see a downside to this.
• same with the npm bundle changes

Needs consideration

• switching from -02 to -0z is going to result in a smaller bundle size, but there will be a degradation of runtime performance. How much? I've no idea. We should add some benchmarks so that we can understand the tradeoffs
• the compression of the wasm text is going to add a tiny bit of overhead to the startup time. Do we know how much it will be?
• as for the wcwidth. That's a piece of the codebase we took from termbox2, so while I'm not opposed to the changes, but I don think we need to make sure we understand it.

[cowboyd]

@natemoo-re

switching from -02 to -0z is going to result in a smaller bundle size, but there will be a degradation of runtime performance. How much? I've no idea. We should add some benchmarks so that we can understand the tradeoffs

Just so we don't block this work, can we merge all the other size optimizations and then consider these C options separately in the context of knowing how runtime perf is impacted?

[natemoo-re]

switching from -02 to -0z is going to result in a smaller bundle size, but there will be a degradation of runtime performance. How much? I've no idea. We should add some benchmarks so that we can understand the tradeoffs

Just so we don't block this work, can we merge all the other size optimizations and then consider these C options separately in the context of knowing how runtime perf is impacted?

@cowboyd yep that sounds like the right path forward! happy to split those out with some benchmarks