Repository navigation
Consider removing unstable "node:module".stripTypeScriptTypes to reduce baseline SEA binary size #57744
Description
Activity
How much does swc add to the binary size?
Around 3MB
Also if you drop amaro its not possible to use type stripping either, not just
module.stripTypeScriptTypesAlso 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.
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.
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.
Reacted by Tobias NießenIf we decide not to support typescript in SEA then it makes sense not to include amaro in it and document that
module.stripTypeScriptTypesis not available. But the api can be stable, the experimental status is not related to the availability in sea.Reacted by Jordan HarbandBy not stabilizing, I was implying to remove the public runtime API everywhere, but I didn’t make that explicit. I’ll update the title.
- changed the title
[-]Consider not stablizing `"node:module".stripTypeScriptTypes` to reduce baseline SEA binary size[/-][+]Consider removing unstable `"node:module".stripTypeScriptTypes` to reduce baseline SEA binary size[/+]on Apr 6, 2025 I disagree we should remove it from everywhere
We can make it unavailable in SEA by documenting that amaro is not available.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.
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 😄
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.
Edit: In response to @ovflowd below, I know Amaro is swc. My point with this comment is that Deno and Node have a similar underlying unfrasturcture.
Reacted by Claudio WunderI 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).
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.
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.
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.
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 ofrequire.(
requireis precisely as statically analyzeable asimport, given that both can be used statically or dynamically)(
requireis precisely as statically analyzeable asimport, given that both can be used statically or dynamically)I never did imply that it is less or more than import. Just saying that it is not fully statically analyzeable 😅
Reacted by Jordan HarbandFWIW, the biggest blob in the Node.js binary isn't something like amaro, but the full ICU data (at least 30M), even if you do not use Intl or prefer to use the system ICU instead of the bundled one (the bundled data may actually be worse than system one, or out of date when there's e.g. timezone changes). If we are talking about reducing the baseline binary size, that leads to the general question about how to remove these components that people may or may not use. For example, changing the build process so that these extra components are appended to the final binary and can be removed easily by binary surgery tools like postject.
Reacted by Claudio Wunder, Marco Ippolito and Jurj Andrei GeorgeFWIW, the biggest blob in the Node.js binary isn't something like amaro, but the full ICU data (at least 30M), even if you do not use Intl or prefer to use the system ICU instead of the bundled one (the bundled data may actually be worse than system one, or out of date when there's e.g. timezone changes). If we are talking about reducing the baseline binary size, that leads to the general question about how to remove these components that people may or may not use. For example, changing the build process so that these extra components are appended to the final binary and can be removed easily by binary surgery tools like postject.
Makes sense to me.
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
I think it would be beneficial to consider not stabilizing
stripTypeScriptTypesand 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.