[benjaminjackman]

Hi Luca - congratulations! I have a quick question, have their been any proposals to add Subresource Integrity hashes (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) to the import syntax? I think this effects Deno more acutely than other projects since Deno supports / (encourages?) directly importing from a url with a precise version number encoded in the url. It would be nice to add another layer of safety on top and be able to assert that the module received is exactly as expected. Thanks!

[gecko]

You can do that right now, albeit not directly in the import: it's done via an explicit `lock.json` file (https://deno.land/manual@v1.16.4/linking_to_external_code/in...). I'm tempted to agree that having some ability either to directly import, or even just to have that better integrated (right now, you have to ask for the lockfile to be used and pass an explicit path), would probably be a good idea.

[benjaminjackman]

Ok that makes a lot of sense, the link you shared helped explain things in denoland quite well (and reminds me that I really need to give it another go).

From the link I see this example:

    in src/deps.ts

    // Add a new dependency to "src/deps.ts", used somewhere else.
    export { xyz } from "https://unpkg.com/xyz-lib@v0.9.0/lib.ts";

    Then essentially a create/update lock-file command is run. 

    Then the lock file is checked into version control. 

    Then another developer checks it out and runs a cache reload command.

As you mentioned in practice it's definitely a bit too manual, but should be one of those things that can be automated so it's not the end of the world.

Having said I think having it in the import syntax would provide a few benefits:

1. No extra steps need to be run & hopefully IDEs could auto-complete the hash.

2. Would hopefully be standardized with the browser allowing for native browser support as well (or perhaps lock.json could be standardized with something like import maps)

3. Having it right there provides an extra level of assurance that the integrity hash is going to be used (especially in files intended to be used in the browser and in deno ... not sure how common that is though).

[lucacasonato]

I am not aware of any specific proposals right now. There was some talk a while back about supporting SRI hashes inside of an import map, but that sorta dissolved. For Deno at least you can use a `lock.json` file with the `--lock` and `--lock-write` flags: https://deno.land/manual/linking_to_external_code/integrity_...

[inbx0]

There's an issue for that to be added as part of import assertions https://github.com/tc39/proposal-import-assertions/issues/11...

[spankalee]

I don't think that's going to fly because it's in-band.

[spankalee]

SRI really, really should be out of band, otherwise SRI digest changes invalidate the entire module graph (and import cycles become a major pain).

I think they're much better as a part of import maps, and later fetch maps so they can apply to non-JS resources like CSS.

[benjaminjackman]

I don't think it's clear cut that it should be out of band 100% of the time. I think there are use cases where inline is useful.

Cycles are definitely an issue, I am not sure there is even way to work around that, except to pull the cycles apart (which may not always be possible but is usually not a bad programming practice when it is). However at the library level, libraries tend not to circularly import each other. If it's being done at the inside a project level the build tool would be generating it so dealing with the module graph being invalidated may not be a hassle (or even necessarily a bad thing), in that case it could modify the files or it could be generating a lock file / import map (which I agree has benefits at that level of not forcing every source to be transpiled, but some of that probably still has to happen for module reloading e.g. appended search parameters to the module path for cache invalidation / module reloading during development like vite.js does for example, and realistically given the nature of the ecosystem some transpilation is going to have to happen either because of .ts or just because of browser differences).

For a top-level deps.ts / dep.js file pattern there probably won't be any cycles. That pattern is to declare a root deps.js file for your project that locks things down and re-exports from third party libraries a use the exports from that as the basis for other imports. For this pattern I think SRI would be extremely helpful and add enough benefit to justify it (even though SRI may not be used in the cases you listed).

Also for smaller projects or main modules having the SRI hash inline is really helpful.