v136 external flag broken

[adamgreg]

Today esm.sh seems to have stopped propagating the external flag to transitive dependencies. At least, for type declarations. I guess this is related to the rollout of v136.

Some example output from deno info:

$ deno info "https://esm.sh/@radix-ui/[email protected]?external=react,react-dom,@types/react"

...

https://esm.sh/@radix-ui/[email protected]?external=react,react-dom,@types/react (707B)
├─┬ https://esm.sh/@radix-ui/[email protected]/X-ZUB0eXBlcy9yZWFjdCxyZWFjdCxyZWFjdC1kb20/dist/index.d.mts (2.33KB)
│ ├── npm:/[email protected]/compat (1.36MB)
│ └─┬ https://esm.sh/@radix-ui/[email protected]/dist/index.d.mts (2.7KB)
│   └─┬ https://esm.sh/@types/[email protected]/index.d.ts (167.2KB)
│     ├── https://esm.sh/@types/[email protected]/global.d.ts (7.2KB)

It looks like the URL for @radix-ui/react-primitive does not propagate the flags, and so it ends up importing @types/react from esm.sh, when it should be external.

I have a Deno Fresh project, and use esm.sh to alias React for Preact, so this is a major problem. For now should I add /v135/ to the URLs in my import map?

[ije]

thanks, i will look into it.

[rschristian]

The Preact team is seeing some similar issues from users using esm.sh, seemingly from ?external not quite working in the same fashion as it did.

For example, preact/hooks depends on preact, and in the past, using https://esm.sh/preact/hooks?external=* would result in a module with a bare preact specifier. As of a day or so ago, it instead results in a module with this specifier: /[email protected]/es2022/preact.mjs.

---

Thanks for all the work you do to maintain this! The ecosystem as a whole really appreciates your time & effort.

[adamgreg]

Hi @ije , thanks for looking into it, but I don't think your update fixed my original issue (which does not involve ?external=*).

If I clear my cache and run the deno info command from the issue's description again, I get the same output, which includes https://esm.sh/@types/react even though it is marked as external in the original URL.

Please could this be re-opened?

[ije]

yeah PR #1036 did fix this issue accutally, i will open another PR for this ASAP

[adamgreg]

Thank you!

[lishaduck]

@ije, this still seems to be happening. Is there a workaround? What's needed to get it fixed?