Inconsistent version pinning

[quentinadam]

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/moment@2.29.4, I am getting the following code which (correctly) "forwards" the v117 version pin :

/* esm.sh - moment@2.29.4 */
export * from "https://esm.sh/v117/moment@2.29.4/es2022/moment.mjs";
export { default } from "https://esm.sh/v117/moment@2.29.4/es2022/moment.mjs";

But when requesting https://esm.sh/v117/preact@10.13.2, I am getting the following code which has (incorrectly) transformed the v117 version pin into stable :

/* esm.sh - preact@10.13.2 */
export * from "https://esm.sh/stable/preact@10.13.2/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/preact@10.13.2/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.

[ije]

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.

[quentinadam]

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/preact@10.13.2, Deno will cache https://esm.sh/stable/preact@10.13.2 and https://esm.sh/stable/preact@10.13.2/es2022/preact.mjs but also https://esm.sh/v117/preact@10.13.2/src/index.d.ts (because this is returned by the X-TypeScript-Types header when requesting https://esm.sh/stable/preact@10.13.2).

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/preact@10.13.2/src/index.d.ts is not cached in deno.lock.

Would it make sense that a request to https://esm.sh/stable/preact@10.13.2 would return https://esm.sh/stable/preact@10.13.2/src/index.d.ts for the location of the type definitions instead of https://esm.sh/v117/preact@10.13.2/src/index.d.ts ?

[renhiyama]

Tldr; d.ts files for ui libraries must also use stable scope instead of v ig

[quentinadam]

Then I guess there currently is a bug in the esm.sh server because requesting https://esm.sh/stable/preact@10.13.2 is returning https://esm.sh/v117/preact@10.13.2/src/index.d.ts in the X-TypeScript-Types header.

[ije]

Then I guess there currently is a bug in the esm.sh server because requesting https://esm.sh/stable/preact@10.13.2 is returning https://esm.sh/v117/preact@10.13.2/src/index.d.ts in the X-TypeScript-Types header.

yes, the types should be fixed as "stable"

[ije]

in v119, types of stable build are going to be fixed as STABLE_VERSION