Discuss
  • [PROPOSAL] Provide a way to enforce integrity check on module imports

[PROPOSAL] Provide a way to enforce integrity check on module imports

# Michaël Rouges (4 years ago)

As proposed a year ago on an old repository (thanks to ljharb, noticed me that fact), on the browser side, the integrity check should be controllable for each imported module. Actually, it's just impossible to do it without bundling.

tc39/proposal-dynamic-import#76

What's your opinion on this, please?

Michaël Rouges - Lcfvs - @Lcfvs

# Jordan Harband (4 years ago)

That seems like something that could possibly be achieved via tc39/proposal

# Guy Bedford (4 years ago)

The problem with inlining the integrity into every import site is that this is naturally incompatible with import maps.

# Bergi (4 years ago)

The problem with inlining the integrity into every import site is that this is naturally incompatible with import maps.

I don't see a problem with that. When using import maps, you should be able to specifiy the integrity check in the import map, not needing it in the module itself. When not using import maps, specifying the integrity in the importing module itself seems to give the best developer experience, following the rationale of tc39/proposal-import-assertions#why-not-out-of-band. When using it in both places, then of course both integrity checks would need to match, and an import map would be prevented from swapping out the module under your hands.

kind , Bergi

# Augusto Moura (4 years ago)

Maybe a convention between hosts to prefix an import with an integrity check?

import foo from 'sha1sum:ef70d15a0700d2108e0df27dde750f5c682b4697!./foo.js';

It looks kinda of dirty, but the specification allows it (aside from the colon character that is forbidden right now)

This types of urls remember me of a past time when bundlers used to have loaders prefixes, like import style from 'css-loader:./styles.css'

Em sáb., 1 de ago. de 2020 às 14:33, Bergi <a.d.bergi at web.de> escreveu: