Hi, nice article. I'm also exploring the possibility of use native browser import, to avoid bundling.
Some considerations:
In the Backbone ecosystem, the issue of bundling duplicates of dependencies also hit it, long ago. The solution (or workaround) was to define the basic dependencies (Backbone, underscore) as peerDependencies letting for the app define as dependency.
To native import work, all dependencies must be distributed as ES module. Sometimes is not so simple
There's the possibility to use imports map with a polyfill. Here's an example
Using native imports is nice for small apps but for apps with many dependencies the distribution may be difficult (there's the need to resolve all dependencies in node_modules and elsewhere and upload together with app main source, ensuring relative path is adjusted)
In the other side, for testing demoing libraries / small apps, it rocks (compare the needed build setup to run the react version of the example app cited above)
yes "moving" the decision to the app itself can work in certain situations but it also "moves" more complexity to the app which is not ideal in many cases as well 🙈
that is soooo true 😭 we experience it ourselves quite a lot as well... you can publish a "fork" like npmjs.com/package/@bundled-es-modu... but yeah that always comes with maintenance 🙈 I am afraid there is no simple way forward - all we can do is encouraging projects to adopt es modules. I think when node will support es modules a lot will change... it's going to happen - slowly but steadily...
yeah actually we love that polyfill and we are building something that will use it - stay tuned 🤗
yes, for now, we recommend import maps purely for development - production environment should still use a build for performance. We recommend our rollup setup which respects import maps while building your performance optimized files.
yeah having no need for any build step while developing feels so freeing :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, nice article. I'm also exploring the possibility of use native browser import, to avoid bundling.
Some considerations:
In the Backbone ecosystem, the issue of bundling duplicates of dependencies also hit it, long ago. The solution (or workaround) was to define the basic dependencies (Backbone, underscore) as peerDependencies letting for the app define as dependency.
To native import work, all dependencies must be distributed as ES module. Sometimes is not so simple
There's the possibility to use imports map with a polyfill. Here's an example
Using native imports is nice for small apps but for apps with many dependencies the distribution may be difficult (there's the need to resolve all dependencies in node_modules and elsewhere and upload together with app main source, ensuring relative path is adjusted)
In the other side, for testing demoing libraries / small apps, it rocks (compare the needed build setup to run the react version of the example app cited above)
thxxx :)