This is a pretty bad default because it is very likely to break any libraries that have singletons. Here's one example, but this is not gonna be an uncommon issue:
The default bundling behavior of ESM.sh means that esm.sh does not behave how ES Modules are specified to behave.
I had broken apps due to duplicate modules plenty of times due to, for example, incompatible versions. But ESM.sh doing this as a default greatly increases this chance. It's like a booby trap for libraries with singletons (f.e. Solid.js, and I've experienced issues with duplicate React libs in the past too).
Example of duplication:
The lume package imports the three package. In the entry point,
and search for "limegreen", you will find a duplicate in each file. That limegreen is from the three package.
Not only is there a massive amount of duplication happening, this is brittle code that is likely to break with if there's a singleton anywhere after updating a version number. And it won't be the library author's fault, but they might get unwanted bug reports from users that don't know it is esm.sh that caused the error.
Solution
Bundling should be entirely optional, and the risk should be clearly outlined in the documentation.
The default should be pure ES Modules that behave exactly as intended.
Minification of each file would be ok, but I think all optimizations should be opt-in (I've had broken code from minifcation, and sometimes new syntax breaks a minifier).
The most ideal setup would be:
start with plain ES Modules unmodified
allow URL options to turn on optimizations, and if they don't work a user can avoid them, but at least their code won't be broken by default.
ije
commented
10 months ago
This is a pretty bad default because it is very likely to break any libraries that have singletons. Here's one example, but this is not gonna be an uncommon issue:
The default bundling behavior of ESM.sh means that esm.sh does not behave how ES Modules are specified to behave.
I had broken apps due to duplicate modules plenty of times due to, for example, incompatible versions. But ESM.sh doing this as a default greatly increases this chance. It's like a booby trap for libraries with singletons (f.e. Solid.js, and I've experienced issues with duplicate React libs in the past too).
Example of duplication:
The
lumepackage imports thethreepackage. In the entry point,https://esm.sh/lume@0.3.0-alpha.30/dist/index.js
we can see a bunch of other imports that it depends on. If you look at a few files from there,
and search for "limegreen", you will find a duplicate in each file. That
limegreenis from thethreepackage.Not only is there a massive amount of duplication happening, this is brittle code that is likely to break with if there's a singleton anywhere after updating a version number. And it won't be the library author's fault, but they might get unwanted bug reports from users that don't know it is esm.sh that caused the error.
Solution
Bundling should be entirely optional, and the risk should be clearly outlined in the documentation.
The default should be pure ES Modules that behave exactly as intended.
Minification of each file would be ok, but I think all optimizations should be opt-in (I've had broken code from minifcation, and sometimes new syntax breaks a minifier).
The most ideal setup would be: