tc39 / proposal-import-attributes

Proposal for syntax to import ES modules with assertions
https://tc39.es/proposal-import-attributes/
Apache License 2.0
599 stars 26 forks source link

Support gating with Progressive Enhancement or Graceful Degredation #153

Open Westbrook opened 8 months ago

Westbrook commented 8 months ago

With import attributes being a feature of module imports that hoist, has there been thought put into how to support them with Progressive Enhancement or Graceful Degredation? Maybe this is enough:

try {
  import('./styles.css', { with: { type: 'css' } });
  import('./modern.js');
} catch (e) {
  import('./legacy.js');
}

But it feels so awkward to rely on try/catch with dynamic imports, which may later have more dynamically imported content included, powering the feature gate.

This is so much like the move to ES Modules at large where we got access to nomodule to unlock access to a build with modules and a separate one without. A noattributes sort of attribute could be a great place to start the conversation.

I remember a lot of feature checking conversation in the wake of nomodule, so maybe there are better options in the intervening years?

nicolo-ribaudo commented 8 months ago

For the existence of import attributes at all, this proposal has been so far considered like any other syntax proposal: either the platforms you are targeting support it, or you just don't ship the unsupported syntax (since a/b detection for syntax is generally difficult to do).

If you want to feature-detect support for it, you would need some sort of eval to "hide" the syntax error so that it does not prevent the whole script from evaluating. This is the same as for any other new syntax:

try {
  new Function("import('', {})");
  import("./modern.js");
} catch {
  import("./legacy.js");
}

You can also use a polyfill to add support for import attributes to older browsers, such as https://github.com/guybedford/es-module-shims.

I think it would be incredibly useful if <script> elements supported something like the media attribute on <link> elements (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#media), such as that you could do

<script src="./modern.js" supports="css-modules and optional-chaining"></script>
<script src="./modern.js" supports="not (css-modules and optional-chaining)"></script>

but I don't think this should be specific to import attributes -- it should be a generic mechanism for new JS features.

Westbrook commented 8 months ago

Yes, a supports attribute would be amazing! Where’s the right part of the world to push for that spec?

nicolo-ribaudo commented 8 months ago

The best venue would be https://github.com/whatwg/html/issues, which is where the <script> element is defined. You'll need to write a description in an issue, discuss the semantics of it and get two browsers to say that they like the idea.

I remember that there was already some (unofficial?) discussion about this in the past somewhere, but I cannot find it anywhere. However, now that CSS has @supports maybe it could be used as a precedent to justify this feature and push it through.

gibson042 commented 8 months ago

https://github.com/tc39/proposal-import-attributes/issues/56#issuecomment-629698719 is a relevant prior comment, with strawperson fallback syntax like so:

// Import config with type "wasm" if possible, otherwise with type "json".
import '//test.local/config' with { type: "wasm" },
       '//test.local/config' with { type: "json" }

// Import an empty module if `0m` is valid syntax, otherwise import a BigDecimal polyfill.
import '/empty.mjs' with { condition: { "validSyntax": "0m" } },
       '/polyfills/BigDecimal.mjs'

For the OP here, maybe something like

import styles from './styles.css' with { type: "css" },
                   './styles.mjs';