Re: [w3c/FileAPI] Support `Response` in `URL.createObjectURL` (#97)

@mkruisselbrink even if the loader/html hook gets added you would still need this to create a few scenarios. Namely any sort of source code transformation cannot be fully solved by the request data hook being added. So things like instrumenting code to have coverage/do local code transformations would not work unless you have a URL it can resolve to. Lets assume we have a transform of some kind that is attempting to allow `import` of JSON by creating one of these Synthetic ESM. This would turn JSON responses ~=

```mjs
import json from './foo.json';
```

To redirect to some newly created ESM record:

```mjs
// foo.json
export default JSON.parse(...)
```

We have a few things going on here.

1. fetching `./foo.json`
   i. this Response could be to a failure / not ok
2. Creating a URL for the ESM facade so that it can be imported
3. Populating that ESM facade URL
4. Redirecting `./foo.json` specifier to a new ESM Response URL

The problems I am currently facing are:

* I cannot represent not ok Responses as Synthetic URLs in any way. That is part of the feature add of this issue.
* I cannot represent or transform any ESM graph that has a cycle in it due to being unable to generate bodies after reserving a `blob:` URL. This would also be addressed by this current issue.
* I cannot rely on the life of `blob:` URLs from Service Workers / browsers don't let me use `URL.createObjectURL` in SW. This seems to be a combination of browser implementations not implementing this part of spec, and the fact that I can't create URLs for `clients` except through the cache mechanism with its limited functionality.
* I cannot at runtime hook into the `import` mechanism in any way so I'm doing lots of ahead of time transforms and *many* extra network requests (solved by the [HTML spec issue](https://github.com/whatwg/html/issues/2640))

Only one aspect of this would be solved by that request data hook being added to the HTML spec.

For more complex problems like source code transformation for JSX / Babel / code coverage / etc. doing transformations off the main UI thread is also ideal. However, doing this on the UI thread is possible.

I also am coming at this from a Node.js implementer perspective and am seeking to create a parity between the two platforms while we work on our hooks for ESM. Node does not currently have a `blob:` scheme in our loader, but we are trying to figure out the best way to create a sane semi-consistent workflow across the two environments. If that requires a new API/scheme, that seems doable but I remain hesitant to think that a new scheme is going to be any less leaky.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/97#issuecomment-365070256