It's unclear how to apply import maps to a worker. There are essentially three categories of approach I can think of:
The worker-creator specifies the import map, e.g. with new Worker(url, { type: "module", importMap: ... })
The worker itself specifies the import map, e.g. with self.setImportMap(...) or import "map.json" assert { type: "importmap" }.
The HTTP headers on the worker script specify the import map, e.g. Import-Map: file.json or maybe even Import-Map: { ... a bunch of JSON inlined into the header ... }.
The worker-creator specified import map is a bit strange:
It's unlike the Window-context mechanism in that the creator of the realm controls the realm's module resolution, instead of the realm itself
It's like the Window-context mechanism in that the script that runs in the realm does not control the realm's module resolution; the control is external to the script itself.
Basically, there is no clear translation of <script type="importmap"> into a worker setting.
Also, as pointed out below, anything where the creator controls the import map works poorly for service worker updates.
The worker itself specifying seems basically unworkable, for reasons discussed below.
And the header-based mechanism is hard to develop against and deploy.
Original post, for posterity, including references to the old "package name map" name
We have a sketch of an idea for how to supply a package name map to a worker:
```js
new Worker(someURL, { type: "module", packageMap: ... });
```
This is interesting to contrast with the mechanism for window contexts proposed currently (and discussed in #1):
- It's unlike the Window-context mechanism in that the creator of the realm controls the realm's module resolution, instead of the realm itself
- It's like the Window-context mechanism in that the script that runs in the realm does not control the realm's module resolution; the control is external to the script itself.
Basically, there is no clear translation of ` Githubissues.
Githubissues is a development platform for aggregating issues.
It's unclear how to apply import maps to a worker. There are essentially three categories of approach I can think of:
new Worker(url, { type: "module", importMap: ... })self.setImportMap(...)orimport "map.json" assert { type: "importmap" }.Import-Map: file.jsonor maybe evenImport-Map: { ... a bunch of JSON inlined into the header ... }.The worker-creator specified import map is a bit strange:
Basically, there is no clear translation of
<script type="importmap">into a worker setting.Also, as pointed out below, anything where the creator controls the import map works poorly for service worker updates.
The worker itself specifying seems basically unworkable, for reasons discussed below.
And the header-based mechanism is hard to develop against and deploy.
Original post, for posterity, including references to the old "package name map" name
We have a sketch of an idea for how to supply a package name map to a worker: ```js new Worker(someURL, { type: "module", packageMap: ... }); ``` This is interesting to contrast with the mechanism for window contexts proposed currently (and discussed in #1): - It's unlike the Window-context mechanism in that the creator of the realm controls the realm's module resolution, instead of the realm itself - It's like the Window-context mechanism in that the script that runs in the realm does not control the realm's module resolution; the control is external to the script itself. Basically, there is no clear translation of ` Githubissues.