You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since March 2018 there is an open ticket to also enable their support for Worker, SharedWorker & ServiceWorker without any progress: WICG/import-maps#2
For me, being the author of a JavaScript (off the main thread) multithreading framework: https://github.com/neomjs/neo, not having the support for the worker scope is a showstopper / blocker.
This mostly affects the micro frontends topic. Use case: An application worker loads apps & components which are specified as JS modules, using import statements. Right now it is impossible to use importmaps here (unless hacking a compile step in there to manually replace relative paths).
Now devs could create additional npm packages to create components or child-apps, which would import framework base-classes from a different path / folder. This can easily result in getting multiple versions of the same file. Not only problematic for file size, but has a potential to break things (imagine importing 2 different IdGenerator classes).
In case the app worker had an import map, all framework related imports would point to the same source of truth.
It would make a big impact and make a lot of devs who would like to create JavaScript code which runs without a build step very happy, in case this feature was in place.
Description
At this point, according to MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap, Chrome, Firefox, Opera & Safari have added support for importmaps ONLY for main threads.
Since March 2018 there is an open ticket to also enable their support for Worker, SharedWorker & ServiceWorker without any progress: WICG/import-maps#2
For me, being the author of a JavaScript (off the main thread) multithreading framework: https://github.com/neomjs/neo, not having the support for the worker scope is a showstopper / blocker.
This mostly affects the micro frontends topic. Use case: An application worker loads apps & components which are specified as JS modules, using import statements. Right now it is impossible to use importmaps here (unless hacking a compile step in there to manually replace relative paths).
Now devs could create additional npm packages to create components or child-apps, which would import framework base-classes from a different path / folder. This can easily result in getting multiple versions of the same file. Not only problematic for file size, but has a potential to break things (imagine importing 2 different IdGenerator classes).
In case the app worker had an import map, all framework related imports would point to the same source of truth.
It would make a big impact and make a lot of devs who would like to create JavaScript code which runs without a build step very happy, in case this feature was in place.
Thanks a lot!
Tobias
Specification
https://github.com/WICG/import-maps
Additional Signals
No response
The text was updated successfully, but these errors were encountered: