Open longnguyen2004 opened 1 year ago
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
JSDelivr has a helpful tool for converting an unpkg URL to their jsdelivr url here:
In my related comment, I suggested using Skypack to help with package compatibility: https://github.com/sveltejs/svelte.dev/issues/848
jsDelivr also has esm.run, which does ESM conversion and minification as well.
@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 :smile:)
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?
Yep I monitor jsDelivr mentions in case someone needs help
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
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.
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?
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.
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
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.
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
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.