Ohh right ... thanks for pointing out

Hi thanks.
Actually I don't need to bundle Matterbridge.
The point is if it is possible to have the matter.js dependency package buid in a production version since it is used in a production environnement.
This as I said is just to save space, time and memory.
In production I don't need types map and comments.
Am I missing something?

You don't need to actually bundle... You mentioned a build stage so I'm assuming you have tooling you are using to package up matterbridge, which includes copying dependencies into some type of dist location.

If you were to implement this copy step using esbuild, you could do something like:

esbuild $NODE_MODULES/@matter/**/*.js $DIST_NODE_MODULES/@matter

If you also copied the package.json files this would produce a directory of matter.js files that is bare JS without comments, source maps or type declarations, which is the same as what you'd get if you were to transpile using tsc with the tsconfig you provided (except much faster).

Note though that this would take up significantly more space than if you were to actually bundle because without tree shaking it wouldn't drop unnecessary files, and individual separate files would consume more blocks on disk.

We could do this step for you in specialized releases like @Apollon77 proposed but the previous point makes their general utility a little fuzzy to me. Typically if a dev is building for an environment where space is at a premium I'd expect that rather than deploying raw NPM packages you'd be using one of many high-quality JS tooling options that solves the problem with a greater degree of flexibility.

LMK if that makes sense. I'm not opposed to the idea, more just unsure where it would fall on the priority list.

Hi,
thanks so much for your detailed answer. I get your point now.

Is not a priority right now: the space itself (we have enough of it 8GB). The time to download files that are not needed in production is not optimal but manageable.

The biggest priority is right now the memory optimization of Endpoint and the memory spikes in the first 2 minutes.
And the performance issues causing the subscription to fail.
These 2 problems together make the move to the new api a failure for the whole project instead of a success.