Consider removing unstable "node:module".stripTypeScriptTypes to reduce baseline SEA binary size

[dsherret]

I think it would be beneficial to consider not stabilizing stripTypeScriptTypes and instead require users to specify a dependency on swc or whatever library they wish.

Reason: This enables Node single executable applications to stay small and not have every binary have a dependency on swc. Instead users can choose to increase their binary size by specifying a dependency only when they need it and not always.

Sure, current design constraints might mean it's currently always required, but in the future work could be done on Node to make this not the case. For example in Deno our single executable applications are custom smaller binaries that do not include swc and we do all the transpiling work up-front when compiling instead of at runtime.

An alternative to this could be making it opt-in to include this API in single executable applications, but overall I think it's much simpler to just require users to specify a dependency because this is a niche use case and also it makes code work the same way across different versions of Node.

[RaisinTen]

How much does swc add to the binary size?

[RaisinTen]

cc @marco-ippolito

[marco-ippolito]

Around 3MB

[marco-ippolito]

Also if you drop amaro its not possible to use type stripping either, not just module.stripTypeScriptTypes

[dsherret]

Also if you drop amaro its not possible to use type stripping either

It is if it's re-architected to be done ahead of time when creating the executable. Not sure if it's done already, but that's what we do in Deno.

An additional benefit is SEAs start faster because they don’t need to transpile on each run.

[RaisinTen]

There might be some confusion here - node sea doesn't have native typescript support yet. When I implement it, I agree that transpiling the code ahead of time and injecting that code is better than injecting the original code and transpiling on each run.

Marco is probably referring to the other existing ways of doing type stripping in node which is separate from node sea. Those won't work if we drop amaro from node. Maybe it could be made to work if node uses amaro as an optional node_modules dep but I'll let Marco answer that.

[dsherret]

Ah, ok I’m not suggesting to remove type stripping from node itself, but just the user facing runtime API for the reasons stated above.

[marco-ippolito]

If we decide not to support typescript in SEA then it makes sense not to include amaro in it and document that module.stripTypeScriptTypes is not available. But the api can be stable, the experimental status is not related to the availability in sea.

[dsherret]

By not stabilizing, I was implying to remove the public runtime API everywhere, but I didn’t make that explicit. I’ll update the title.

[marco-ippolito]

I disagree we should remove it from everywhere
We can make it unavailable in SEA by documenting that amaro is not available.

[dsherret]

I don’t think that’s viable because over time users will complain that certain things don’t work in SEA. Also, by adding this API, other execution environments other than SEA that offer node compatibility are being bloated (ex. workerd).

What’s the issue with users just including the dependency the classic way if they need it? This use case is niche.

[marco-ippolito]

I'm working on other APIs that rely on amaro (#57731)
I think its fair to add a SEA config to enable/disable amaro so users can opt in/out.

The request of removing an API because of other runtimes feels wild 😄

[dsherret]

The request of removing an API because of other runtimes feels wild 😄

It was a secondary point and not the main point. For example personally in Deno we use swc.

[marco-ippolito]

I see your point, actually having a way to opt-in/opt out some modules in SEA would be beneficial, like amaro, crypto, npm (mentioning those because I know its possible to build node without them).

[dsherret]

That's more reasonable if it's possible and feasible to do that.

Side note: this overall trend in JS runtimes to just have built-in APIs for stuff that could be a library is not great for the long term health of the JS ecosystem in my opinion. So much bloat, runtime specific code, and extra complexity across the ecosystem for functionality that could have easily been specified as a dependency and be decoupled from the runtime where it would work in even old versions of node.js.

[RaisinTen]

Opting out of those modules requires building node from source. While it's definitely possible, SEA builders will find it inconvenient to build node from source.

[ovflowd]

The request of removing an API because of other runtimes feels wild 😄

It was a secondary point and not the main point. For example personally in Deno we use swc.

Amaro is swc.

[ovflowd]

This is more a discussion of allowing SEA to be ahead-of-time and interpolating what node: namespaces are being used within the binary you are generating. Which is a nice idea, but quite challenging as SEA is CJS-only and that is not statically analyzable at the moment due to the nature of require.