Baseline "limited availability" for ESM?

[lionel-rowe]

Originally reported in mdn/browser-compat-data.

Articles for Modules and import both claim "limited availability", but the article for export has "widely available".

I guess it's something to do with support for typed imports using with and the legacy assert, but I don't think those are what people would understand by "support for modules" or "support for import statements".

I had a look in js-modules.yml in the current repo, but all the features cited there are widely supported — even nomodule looks to be supported in Safari 11 (Sep 2017), according to MDN.

[foolip]

I think the problem is that javascript.statements.import is part of both CSS modules and JS modules. When yari finds a web feature by compat key, it probably finds CSS modules first because it comes first alphabetically. And CSS modules is only supported in Chromium browsers.

This fix should be to remove javascript.statements.import from CSS modules in web-features.

[captainbrosset]

When yari finds a web feature by compat key, it probably finds CSS modules first because it comes first alphabetically.

I didn't know how yari mapped MDN pages to web-features, but this way sounds prone to bugs.

This fix should be to remove javascript.statements.import from CSS modules in web-features.

Ensuring that we use BCD keys just once in the repo feels like an arbitrary limitation that will be a problem for us in the future.
I'm not apposed to doing this as a quick fix if this unblocks MDN. But would this work long term:

MDN optionally associates articles with web-features (probably by adding a webFeaturesId: js-modules entry in the front matter). For articles that have this association, that's how the right web-features dist file is pulled. For others, they continue doing what they do now.
As a bonus: we get MDN links for free, for some of our features.