esm-dev
Inconsistent version pinning
When pinning the esm.sh server version, it does seem to work as expected for some packages but not for others.
For example:
When requesting https://esm.sh/v117/[email protected], I am getting the following code which (correctly) "forwards" the v117 version pin :
/* esm.sh - [email protected] */
export * from "https://esm.sh/v117/[email protected]/es2022/moment.mjs";
export { default } from "https://esm.sh/v117/[email protected]/es2022/moment.mjs";
But when requesting https://esm.sh/v117/[email protected], I am getting the following code which has (incorrectly) transformed the v117 version pin into stable :
/* esm.sh - [email protected] */
export * from "https://esm.sh/stable/[email protected]/es2022/preact.mjs";
As a result, when working with Deno and deno.lock, when the version pin is transformed to stable, it can lead to unexpected "The source code is invalid, as it does not match the expected hash in the lock file." errors. These errors happen because Deno caches the content of "https://esm.sh/stable/[email protected]/es2022/preact.mjs", but that content may sometimes change whenever stable is pointing to a different server version that generates a different content, like what happened this week.
For UI libraries like React and Vue, esm.sh uses a special build version stable to ensure single version of the library is used in the whole application, even you pin it to a fixed build version.
Ok, the issue that I am encountering because of this is the following:
From within the context of a Deno project, when caching a dependency such as https://esm.sh/stable/[email protected], Deno will cache https://esm.sh/stable/[email protected] and https://esm.sh/stable/[email protected]/es2022/preact.mjs but also https://esm.sh/v117/[email protected]/src/index.d.ts (because this is returned by the X-TypeScript-Types header when requesting https://esm.sh/stable/[email protected]).
At a later stage, when my app is being run in production from within a clean Docker context, and if the esm.sh server version has been updated (for example to v118), when running the code with deno run --cached-only, it will fail because Deno will complain that https://esm.sh/v118/[email protected]/src/index.d.ts is not cached in deno.lock.
Would it make sense that a request to https://esm.sh/stable/[email protected] would return https://esm.sh/stable/[email protected]/src/index.d.ts for the location of the type definitions instead of https://esm.sh/v117/[email protected]/src/index.d.ts ?
Tldr; d.ts files for ui libraries must also use stable scope instead of v
Then I guess there currently is a bug in the esm.sh server because requesting https://esm.sh/stable/[email protected] is returning https://esm.sh/v117/[email protected]/src/index.d.ts in the X-TypeScript-Types header.
Then I guess there currently is a bug in the esm.sh server because requesting https://esm.sh/stable/[email protected] is returning https://esm.sh/v117/[email protected]/src/index.d.ts in the X-TypeScript-Types header.
yes, the types should be fixed as "stable"