I would like to reopen the discussion about preload metadata as mentioned in https://github.com/WICG/import-maps#supplying-out-of-band-metadata-for-each-module and previously discussed in #21.

From the comment in the README, the allusion is towards a general manifest here, as purely an illustration, something like:

<script type="preload-manifest">
{
  "https://site.com/path/to/module.js": {
    "integrity": "...",
    "preloads": [{
      "href": "./x.js",
      "rel": "modulepreload"
    }]
  },
  "https://site.com/path/to/x.js": {
    "integrity": "...",
    "credentials": "include",
    // eg dynamic import, alternatively some kind of priority system
    "lazyPreloads": [{
      "href": "import:dep",
      "rel": "modulepreload"
    }]
  }
}
</script>

Note that the "integrity" and other preload information does not associate with the dependency entry itself, but rather associates with the top-level entry. This is to avoid repeated information (and possibly conflicting information), in line with such a manifest being able to be a single source of truth.

In trying to specify something along these lines I'm hitting some conceptual issues, and would value some feedback on how such a thing might work:

1. Strictly speaking, having purely a URL as the key in the manifest is not enough information for a general manifest. For example, fetch('https://site.com/path/to/module.js') should probably not trigger the preloading. That is, the preloading information needs to apply alongside the type of interpretation, currently captured by the "rel" or "as" attributes. Since the same resource may have multiple representations / loading profiles depending on how it is loaded. It should probably be something more like:

<script type="preload-manifest">
[
  {
    "url": "https://site.com/path/to/module.js",
    "rel": "modulepreload",
    "integrity": "...",
    "preloads": [...]
  },
]
</script>

This way each entry can participate in the preload system corresponding to its correct interpretation directly. At this point the manifest starts to look pretty convoluted though. Is there a solution to this problem?

2. Dependencies like import 'dep' can only use an href attribute to reference their dependency that is resolved through an import map when we assume support for import:dep URLs. These import: URLs are effectively a prerequisite for such a manifest. Are we sure this syntax will continue to make progress?

3. No one is currently working on a specification for this feature that I know of, and that is probably the biggest issue of all. I have had discussions with various browser implementors and spec authors over the past year and I found there to be little interest in this work at a general level. How can we bring together the interested parties to start this spec work? In terms of trying to scope the work - would this work be seen as an extension of the preload sections of the HTML specification? Or perhaps something that integrates into the fetch specification? Or even as its own specification entirely? I'd be happy to be involved in this process further, but there seems to be quite some uphill here since there are no browsers feeling direct pain points today that are solved by this feature. Just generating such interest is a job unto itself!

I'm opening this issue here because preload is very much related to modules and the design space of this specification, and even if this work is another spec process, getting feedback and some driving directions from this group seems the appropriate way to start along this path.

Thanks for suggestions in advance!