esm-dev / esm.sh

The no-build CDN for modern web development.
https://esm.sh
MIT License
3.15k stars 151 forks source link

Failed to import - @mdn/browser-compat-data #907

Open bosconian-dynamics opened 3 days ago

bosconian-dynamics commented 3 days ago

It is possible that I am overlooking some obvious solution here.

Failing module

import { getAppropriateEcmaVersionForBrowserslist } from "https://esm.sh/browserslist-generator@3.0.0"

Error message

After onload I got this:

GET https://esm.sh/v135/@mdn/browser-compat-data@5.6.14/es2022/browser-compat-data.mjs net::ERR_ABORTED 500 (Internal Server Error)    browserslist-generator@3.0.0:4 

The code responsible for the request (browserslist-generator@3.0.0:4) is the following import:

import "/v135/@mdn/browser-compat-data@5.6.14/es2022/browser-compat-data.mjs";

The response body at the indicated URL consists of the following:

/* esm.sh - error */
throw new Error("[esm.sh] " + "esmLexer: invalid syntax, require javascript/typescript");
export default null;

Additional info

The crux of the issue seems to be the attempt to import the @mdn/browser-compat-data@5.6.14 package. I'm not really sure what's supposed to be at @mdn/browser-compat-data@5.6.14/es2022/browser-compat-data.mjs as this file is not part of the package or release.

I've made some attempts to solve the issue via aliasing.

Aliasing to the RAW JSON file

import { getAppropriateEcmaVersionForBrowserslist } from "https://esm.sh/browserslist-generator@3.0.0?alias=@mdn/browser-compat-data:@mdn/browser-compat-data@5.6.14/data.json?raw";

This produces the following import statement, which does indeed produce the raw JSON file

import "/v135/@mdn/browser-compat-data@5.6.14/es2022/data.json?raw.js";

However it ultimately results in the error

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "application/json". Strict MIME type checking is enforced for module scripts per HTML spec.

Aliasing to the JSON file with module transformation

import { getAppropriateEcmaVersionForBrowserslist } from "https://esm.sh/browserslist-generator@3.0.0?alias=@mdn/browser-compat-data:@mdn/browser-compat-data@5.6.14/data.json";
import "/v135/@mdn/browser-compat-data@5.6.14/es2022/data.json.js";
/* esm.sh - @mdn/browser-compat-data@5.6.14/data.json */
export * from "/v135/@mdn/browser-compat-data@5.6.14/es2022/data.json.js";
export { default } from "/v135/@mdn/browser-compat-data@5.6.14/es2022/data.json.js";

For all purposes this looks like it should work. However, when another module executes the following import statement:

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

the compatData object only has a default member containing the contents of the JSON object, and the subsequent code does not handle that nesting.

EDIT: This may actually be an issue inherent to the package itself which results in the ESM import erroneously nesting the data into the default export. If this is fixed, this alias solution should work.

Aliasing to entry point files

I've also tried aliasing to /import.d.mts and require.d.ts by way of /import.d.mjs and /require.d.js - and it was super neat to see that esm.sh actually compiles these TypeScript files for me. But either entry point expects /types.d.ts to have been compiled into /types.js, but esm.sh processes the /types.js URI into the nonexistent resource path

"/v135/.@latest/es2022/types.js"

instead of the existing

"/v135/@mdn/browser-compat-data@5.6.14/es2022/types.d.js"

I've tried to alias the former to the latter but have not succeeded thus far.

ije commented 2 days ago

@bosconian-dynamics thanks for the details!! i will look into it.