wessberg / browserslist-generator

A library that makes generating and validating Browserslists a breeze!
MIT License
91 stars 8 forks source link

The esm dist errors where the commonjs dist works #19

Open ccouzens opened 5 months ago

ccouzens commented 5 months ago

Hello,

Thank you for your project.

I've found that when using browsersWithSupportForFeatures I get an error when using esmodules, but not when using commonjs. I've attached 2 test files below. example.js and example.mjs are effectively the same except for .js uses commonjs and .mjs uses esmodules. The path to the code imported is node_modules/browserslist-generator/dist/cjs/index.cjs for the .js and node_modules/browserslist-generator/dist/esm/index.js for the .mjs.

I've reproduced this on node v18.16.0 and v20.12.2. My browserslist-generator is

      "version": "2.1.0",
      "resolved": "https://registry.npmjs.org/browserslist-generator/-/browserslist-generator-2.1.0.tgz",
      "integrity": "sha512-ZFz4mAOgqm0cbwKaZsfJbYDbTXGoPANlte7qRsRJOfjB9KmmISQrXJxAVrnXG8C8v/QHNzXyeJt0Cfcks6zZvQ==",

example.js

const {browsersWithSupportForFeatures} = require("browserslist-generator");

console.log(browsersWithSupportForFeatures("es6-module", "shadowdomv1", "custom-elementsv1"))

example.mjs

import {browsersWithSupportForFeatures} from "browserslist-generator";

console.log(browsersWithSupportForFeatures("es6-module", "shadowdomv1", "custom-elementsv1"))
% node example.js
[
  'and_chr >= 125',
  'chrome >= 61',
  'and_ff >= 126',
  'edge >= 79',
  'samsung >= 8.2',
  'safari >= 11',
  'ios_saf >= 11.2',
  'opera >= 48',
  'firefox >= 63',
  'unreleased and_chr versions',
  'unreleased chrome versions',
  'unreleased and_ff versions',
  'unreleased edge versions',
  'unreleased samsung versions',
  'unreleased safari versions',
  'unreleased ios_saf versions',
  'unreleased opera versions',
  'unreleased firefox versions'
]
% node example.mjs
(node:19928) ExperimentalWarning: Import assertions are not a stable feature of the JavaScript language. Avoid relying on their current behavior and syntax as those might change in a future version of Node.js.
(Use `node --trace-warnings ...` to show where the warning was created)
file:///xxxxxxxxxxx/node_modules/browserslist-generator/dist/esm/index.js:1175
        throw new TypeError(`The given feature: '${feature}' is unknown. It must be a valid Caniuse or MDN feature!`);
              ^

TypeError: The given feature: 'api.CustomElementRegistry' is unknown. It must be a valid Caniuse or MDN feature!
    at assertKnownFeature (file:///xxxxxxxxxxx/node_modules/browserslist-generator/dist/esm/index.js:1175:15)
    at getFeatureSupport (file:///xxxxxxxxxxx/node_modules/browserslist-generator/dist/esm/index.js:1194:5)
    at browserSupportForFeaturesCommon (file:///xxxxxxxxxxx/node_modules/browserslist-generator/dist/esm/index.js:1317:25)
    at browsersWithSupportForFeatures (file:///xxxxxxxxxxx/node_modules/browserslist-generator/dist/esm/index.js:974:33)
    at file:///xxxxxxxxxxx/example.mjs:3:13
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)

Node.js v18.16.0

I am happy to help solve this, although it may be a few days before I get round to it.

bosconian-dynamics commented 1 week ago

I have just ran into this issue, both within the browser via esm.sh distribution, and within a vanilla Node 22.11.0 environment.

It seems like this import with module attributes results in all of the MDN data getting nested within a default property, which breaks everything expecting it to be available on the top-level object.

import * as compatData from "@mdn/browser-compat-data" with {type: "json"};