[REPL] Switch to jsDelivr

[longnguyen2004]

unpkg has been intermittent for ~6 months. jsDelivr is more resilient, (seems to) supports CORS and also hosts files from GitHub, so switching to it would fix sveltejs/sites#282 as well.

[jimaek]

Let us know if the jsDelivr team can help with anything. jsDelivr is under active development and aims at production use-cases with multi-CDN logic https://www.jsdelivr.com/network/infographic

[sean-mystyle]

JSDelivr has a helpful tool for converting an unpkg URL to their jsdelivr url here:

https://www.jsdelivr.com/unpkg

[theetrain]

In my related comment, I suggested using Skypack to help with package compatibility: #848

[longnguyen2004]

jsDelivr also has esm.run, which does ESM conversion and minification as well.

[benmccann]

@longnguyen2004 thanks for the suggestion (as well as the issues in Svelte itself - sorry we have a hard time keeping up with all the issues 😄)

Let us know if the jsDelivr team can help with anything. jsDelivr is under active development and aims at production use-cases with multi-CDN logic https://www.jsdelivr.com/network/infographic

@jimaek, just curious, how were you made aware of this issue? Do you have a GitHub alert for jsDelivr always running or something?

[jimaek]

Yep I monitor jsDelivr mentions in case someone needs help

[PuruVJ]

Hi, I'm experimenting with jsDelivr in REPL(See sveltejs/sites#551). So far loving it, only issue is that it doesn't resolve barrel imports(https://cdn.jsdelivr.net/npm/radix-svelte/dist/components) while unpkg does(https://unpkg.com/radix-svelte/dist/components). Can be done manually in the REPL by resolving with different methods('.js', '.mjs', '.cjs', './index.js', 'index.cjs', 'index.mjs'), but that would require 7 fetch requests in worst case, which is too much to be doing on user's device.

That is something that would make transitioning very easy. Is this possible to implement on jsdelivr's end? cc @jimaek

[MartinKolarik]

Hi, I'm experimenting with jsDelivr in REPL(See sveltejs/sites#551). So far loving it, only issue is that it doesn't resolve barrel imports(https://cdn.jsdelivr.net/npm/radix-svelte/dist/components) while unpkg does(https://unpkg.com/radix-svelte/dist/components). Can be done manually in the REPL by resolving with different methods('.js', '.mjs', '.cjs', './index.js', 'index.cjs', 'index.mjs'), but that would require 7 fetch requests in worst case, which is too much to be doing on user's device.

That is something that would make transitioning very easy. Is this possible to implement on jsdelivr's end? cc @jimaek

Hey, we support server-side resolving in ESM mode so this would generally work: https://cdn.jsdelivr.net/npm/radix-svelte@latest/dist/components/+esm but here the package declares exports and doesn't expose that directory, so it can't be accessed like that. For packages with no exports it works with all files.

[PuruVJ]

I am facing some weird problems with esm.run, where the output component code just doesn't work with esm.run, but does with regular old jsdelivr. Is there a way to configure the rollup and terser version esm.run uses?

[MartinKolarik]

Is there a way to configure the rollup and terser version esm.run uses?

No, but if the files happen to be built using an older version, we might be able to update them to the version we use at this time.

[benmccann]

We gave up on esm.run because the bundling was causing issues with ending up with multiple versions of the Svelte runtime. jsdelivr would still be interesting though

[benmccann]

Svelte 4 returns a .cjs file for the compiler, which jsdelivr correctly serves with application/node mime-type. However, Chrome doesn't recognize that as JavaScript. That leaves us stuck with unpkg for Svelte 3/4

Svelte 5 avoids this by returning a .js file for the compiler, so we could probably use jsDelivr for Svelte 5

@PuruVJ I'm not sure I understand your mention of radix-svelte above. As far as I'm aware, libraries are bundled by rollup in the browser, so their mime types would not matter and we only need to worry about Svelte itself.

[Rich-Harris]

Where do you anticipate that being a problem? We use fetch and eval to load the compiler, rather than import or importScripts, so it should be fine

[benmccann]

Hey, we support server-side resolving in ESM mode so this would generally work: https://cdn.jsdelivr.net/npm/radix-svelte@latest/dist/components/+esm but here the package declares exports and doesn't expose that directory, so it can't be accessed like that. For packages with no exports it works with all files.

@MartinKolarik can you clarify what directory it's looking for that it can't access? When I visit https://cdn.jsdelivr.net/npm/radix-svelte@latest/dist/components/+esm it just says failed to resolve an internal import, but it's not clear what path it's having difficulty accessing.

[PuruVJ]

Just to clarify, we can’t use +esm since it breaks the svelte runtime due to the shared component instance. What’s to say it won’t break other libs too

…

On Thu, 20 Mar 2025 at 6:51 PM, Ben McCann ***@***.***> wrote: Hey, we support server-side resolving in ESM mode so this would generally work: ***@***.***/dist/components/+esm but here the package declares exports and doesn't expose that directory, so it can't be accessed like that. For packages with no exports it works with all files. @MartinKolarik <https://github.com/MartinKolarik> can you clarify what directory it's looking for that it can't access? When I visit ***@***.***/dist/components/+esm it just says failed to resolve an internal import, but it's not clear what path it's having difficulty accessing. — Reply to this email directly, view it on GitHub <#835 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALMH4F47CTVZTG6SR52L3RL2VK6HBAVCNFSM6AAAAABRVBKQTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBQGQ2DCNZYGU> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: benmccann]*benmccann* left a comment (sveltejs/svelte.dev#835) <#835 (comment)> Hey, we support server-side resolving in ESM mode so this would generally work: ***@***.***/dist/components/+esm but here the package declares exports and doesn't expose that directory, so it can't be accessed like that. For packages with no exports it works with all files. @MartinKolarik <https://github.com/MartinKolarik> can you clarify what directory it's looking for that it can't access? When I visit ***@***.***/dist/components/+esm it just says failed to resolve an internal import, but it's not clear what path it's having difficulty accessing. — Reply to this email directly, view it on GitHub <#835 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALMH4F47CTVZTG6SR52L3RL2VK6HBAVCNFSM6AAAAABRVBKQTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBQGQ2DCNZYGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MartinKolarik]

@benmccann the exact error is Error: Can't resolve './dist/components/Accordion/header.svelte' Note that even if the file exists, it could be missing from exports and hence not allowed to be accessed, and in this specific case, I suspect it would fail upon loading even if configured correctly since it isn't a JS file.

[benmccann]

Thanks for the response @MartinKolarik. It seems I misunderstood @PuruVJ's earlier comment and what exactly it is that we need.

I believe the issue isn't really about barrel files, but about redirecting for directory imports.

https://unpkg.com/[email protected]/dist/components will redirect to https://unpkg.com/[email protected]/dist/components/index.js

On the otherhand, https://cdn.jsdelivr.net/npm/[email protected]/dist/components will 404 rather than redirecting to https://cdn.jsdelivr.net/npm/[email protected]/dist/components/index.js.

Is there any chance that's something that might be able to be implemented on the jsdelivr side? We'd love to make the jump from unpkg to jsdelivr 😄

[MartinKolarik]

Unfortunately I don't think we'll be able to add redirects like that in the near future, but if you're loading the packages dynamically and don't know the final URLs beforehand, maybe our API could help?

You could resolve it on your side with the help of https://data.jsdelivr.com/v1/packages/npm/[email protected]?structure=flat - that's what most browser IDEs and similar tools using us do.

Docs: https://www.jsdelivr.com/docs/data.jsdelivr.com

[Rich-Harris]

It seems to me that radix-svelte is just wrong here, and there's no reason to expect that export * from './components' inside https://cdn.jsdelivr.net/npm/[email protected]/dist/index.js should work (other than the fact that bundlers and unpkg have created those expectations by resolving imports more leniently than the spec). I think I'd personally be okay with packages not working if they have invalid imports.

That said, it seems odd that https://cdn.jsdelivr.net/npm/[email protected] doesn't redirect to ./dist/index.js given its pkg.exports — any idea what's going on there?

[Rich-Harris]

Opened #1244 to investigate switching. Unfortunately not being able to resolve entry points when a pkg.exports is involved is a showstopper — hopefully I've misunderstood something and this is an easy fix

[MartinKolarik]

@Rich-Harris right, we only support exports in the ESM mode, and the "regular" mode only supports the older main/browser fields. If this is a blocker, I think we should be able to add the exports support quickly; it's been on the to-do list for a while.

[MartinKolarik]

That said, the change we could do quickly would only work for the default export path ("."), not for aliased exports like these:

"./internal/*": {
  "types": "./dist/internal/*/index.d.ts",
  "svelte": "./dist/internal/*/index.js"
},

I don't know if you'd need those as well. If yes, it might be a better idea to fetch package.json from us first, then apply full resolving client-side, and then fetch the right files.

[PuruVJ]

@MartinKolarik the codebase already does resolve URLS with exports. The issue is with the directory-style imports, like import Accordian from './lib/Accordian'. That path is not listed anywhere.

While I acknowledge that this is wrong, unpkg has built this habit up for users, and we should keep supporting that going forward, or be at the risk of breaking lot of older REPLs with prior art. Hence why we must bother you 😅

It would be great if jsdeliver could attempt to resolve these directory like imports like unpkg, something akin to ['', '.js', '/index.js', '.mjs', '/index.mjs', '.cjs', '/index.cjs'].reduce(pick_working_suffix). While it is doable on our end, it means the user's browser has to do multiple fetch requests to an external backend just to know which one is functional. Whereas if this happens on jsdeliver backend, itll be instantaneous

[MartinKolarik]

I see, in that case, the best solution really is using the API I mentioned earlier (maybe only for extensionless URLs). The reason we don't do directory/extension resolving directly is we often don't have the full file list (locally) either and would have to make the same extra requests.

[Rich-Harris]

Merged #1248, so I'll close this