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.
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).
