You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If legacy support is added it will likely add security vulnerabilities.
Which is fine... if legacy is opt-in only the user should be warned that it could be dangerous.
The thing to watch out for is that these vulnerabilities are not exposed to the non-legacy / default setup.
This has come up in a few tickets in Sapper and most recently here: sveltejs/sapper#1760
I have not doubt this is a pain, but I am very glad that it is being considered though. These legacy platforms are no fun, but they are still often a reality. Thank y'all for all of the hard work on this project. It really is great!
Reacted by silllli, Luke, Niket Pathak, 汪汪, perqa, Alex and Ibrahim
(I have used a solution based on Antony Jones’ repository (antony/sapper-ie) for IE11 support with Sapper and was quite happy I got it working rather automatically.
If you work on projects for or visited by public institutions in Germany, there are chances that these visitors are using an old, restricted Windows machine. 😢)
If you work on projects for or visited by public institutions in Germany, there are chances that these visitors are using an old, restricted Windows machine. 😢)
@silllli this is exactly my problem. I fear the browser and Windows version are not the real problem. They probably use a white list. Complex JavaScript apps like Google Maps work, but the Svelte test-page (even the legacy test-page) do not work.
Have you found a workaround?
I still use Sapper 🥲
I was also like this, until I have become more aggressive, so I created my own PR #6265 and maintain my own fork of SvelteKit. Please tell me if this PR and the demo have a nice DX for you.
It still requires the browser version to be at least IE11 or something similar though, can't pass through this limit.
It still requires the browser version to be at least IE11 or something similar though, can't pass through this limit.
for me is more than enough, as what i need to support are chrome 49 and opera 32 versions, because of deployed fleets of tvs that included that versions, well, deployed and even new tvs came with that browser versions, so your fork has been a nice thing to start migrating from sapper version.
There's something that we can do to help integrate this fork more easily in the main branch?
It still requires the browser version to be at least IE11 or something similar though, can't pass through this limit.
for me is more than enough, as what i need to support are chrome 49 and opera 32 versions, because of deployed fleets of tvs that included that versions, well, deployed and even new tvs came with that browser versions, so your fork has been a nice thing to start migrating from sapper version.
There's something that we can do to help integrate this fork more easily in the main branch?
This PR is outdated. Please see my own PR based on this one, in #6265.
@Rich-Harris expressed concerns with merging legacy support to the main kit. He suggested this be made into a plugin, rather than core functionality. Would it be possible to maintain this as a fork until there is community consensus?
His other suggestion of progressive enhancement seems woefully at odds with the frameworks of vite and svelte, which take the unique approach of prioritizing modern support and leaving legacy browsers as an afterthought. But I read Vue 3 will not support ES5 out of the box, so this may increasingly become the case.
It has been pointed out that svelte is an unusually speedy framework. I'm wondering what can be done to make it an unusually backward compatible framework as well? Having things break on older devices with no warning or explanation is not a good look.
Edit:
Looks like nginx has some support for browser specific serving. But we don't even have working ES5 builds for svelte projects?
@Rich-Harris expressed concerns with merging legacy support to the main kit. He suggested this be made into a plugin, rather than core functionality. Would it be possible to maintain this as a fork until there is community consensus?
Sadly, that's what I'm doing currently, while still hoping for a solution from the core team.
Another disappointing fact is that I don't see how this feature can be extracted to a plugin in a normal way, since the "logic extraction" is already done by using the external Vite plugin-legacy. The main concern for SvelteKit is to write a legacy-compatible code, while the legacy bundling is done by the external Vite plugin already.
His other suggestion of progressive enhancement seems woefully at odds with the frameworks of vite and svelte, which take the unique approach of prioritizing modern support and leaving legacy browsers as an afterthought. But I read Vue 3 will not support ES5 out of the box, so this may increasingly become the case.
That's not true about Vue 3, see Vue 3 Browser Compatibility.
Basically, the Vite plugin-legacy is a piece of code written by the same guys maintaining Vue, so the same logic, however in a fancier more universal form, is being offered by Vite plugin-legacy.
SvelteKit has an advantage over Vue that it's specific only to the Vite bundler, so we can leverage the hard work that done by the Vite plugin-legacy, we just need to "read" its results correctly, and this is basically what my PR is doing(plus many tests and etc.).
It has been pointed out that svelte is an unusually speedy framework. I'm wondering what can be done to make it an unusually backward compatible framework as well? Having things break on older devices with no warning or explanation is not a good look.
Totally agree!
Edit:
Looks like nginx has some support for browser specific serving. But we don't even have working ES5 builds for svelte projects?
The philosophy of "modern" legacy support is to not distinguish the legacy browsers in the HTTP request level, but on the client level instead, making it so simpler basically for everything (testing/debugging/caching/static-serving...). Thankfully, the solution in the client level is simple enough so you wouldn't naturally like to go to these places.
Reacted by perqa, Francois Paulin, Shane Jaroch, Andy Pan, Michael Karlsson, Caspian Baska, Felix Palmgren, Brendan Matkin and Jokin
@Tal500 Do you have it in the npm registry? As long as it's merged within the last few versions, I don't need the latest. Do we still need the legacy adapter if we're going to use this?
Sapper has been deprecated in favor of SvelteKit. We recommend using SvelteKit.
for all projects moving forward. Sapper will no be receiving security fixes, bug fixes, or any type of improvements.
@Tal500 Do you have it in the npm registry? As long as it's merged within the last few versions, I don't need the latest. Do we still need the legacy adapter if we're going to use this?
Other than that, I would try out Sapper I guess.
Sorry for the long wait, but I think I cannot keep update every time a new kit conflict occurs.
I'll be glad if anyone could help me keep update the versioning, since I don't have time for this side project for now.
Kit 3 requires Svelte 5 (svelte: ^5.56 peer), and Svelte 5's client runtime is built on Proxy ($state objects, rest/spread props), which can't be transpiled and only partially polyfilled. So a legacy differential build of a current Kit app isn't possible even via the plugin route discussed above. I think this can be closed.
Activity
FredKSchott commentedon Oct 16, 2020
[-]Differential builds[/-][+]Differential legacy builds[/+]backflip commentedon Mar 23, 2021
Unverified assumption: https://github.com/vitejs/vite/tree/main/packages/plugin-legacy might help here.
seanlail commentedon Apr 7, 2021
If legacy support is added it will likely add security vulnerabilities.
Which is fine... if legacy is opt-in only the user should be warned that it could be dangerous.
The thing to watch out for is that these vulnerabilities are not exposed to the non-legacy / default setup.
This has come up in a few tickets in Sapper and most recently here:
sveltejs/sapper#1760
Relates to #93
johngrasty commentedon May 14, 2021
I have not doubt this is a pain, but I am very glad that it is being considered though. These legacy platforms are no fun, but they are still often a reality. Thank y'all for all of the hard work on this project. It really is great!
silllli commentedon May 16, 2021
+1 @johngrasty
(I have used a solution based on Antony Jones’ repository (antony/sapper-ie) for IE11 support with Sapper and was quite happy I got it working rather automatically.
If you work on projects for or visited by public institutions in Germany, there are chances that these visitors are using an old, restricted Windows machine. 😢)
23 remaining items
Tal500 commentedon Jan 10, 2023
I was also like this, until I have become more aggressive, so I created my own PR #6265 and maintain my own fork of SvelteKit. Please tell me if this PR and the demo have a nice DX for you.
It still requires the browser version to be at least IE11 or something similar though, can't pass through this limit.
ZaDarkSide commentedon Jan 13, 2023
@Rich-Harris please take a look at the PR #6265 from @Tal500 we need this feature in SvelteKit 👍
jokin commentedon Feb 23, 2023
for me is more than enough, as what i need to support are chrome 49 and opera 32 versions, because of deployed fleets of tvs that included that versions, well, deployed and even new tvs came with that browser versions, so your fork has been a nice thing to start migrating from sapper version.
There's something that we can do to help integrate this fork more easily in the main branch?
Tal500 commentedon Feb 23, 2023
This PR is outdated. Please see my own PR based on this one, in #6265.
gamesguru commentedon Apr 15, 2023
@Tal500
@Rich-Harris expressed concerns with merging legacy support to the main kit. He suggested this be made into a plugin, rather than core functionality. Would it be possible to maintain this as a fork until there is community consensus?
His other suggestion of progressive enhancement seems woefully at odds with the frameworks of
viteandsvelte, which take the unique approach of prioritizing modern support and leaving legacy browsers as an afterthought. But I read Vue 3 will not supportES5out of the box, so this may increasingly become the case.It has been pointed out that
svelteis an unusually speedy framework. I'm wondering what can be done to make it an unusually backward compatible framework as well? Having things break on older devices with no warning or explanation is not a good look.Edit:
Looks like
nginxhas some support for browser specific serving. But we don't even have workingES5builds forsvelteprojects?https://nginx.org/en/docs/http/ngx_http_browser_module.html
Tal500 commentedon Apr 15, 2023
Sadly, that's what I'm doing currently, while still hoping for a solution from the core team.
Another disappointing fact is that I don't see how this feature can be extracted to a plugin in a normal way, since the "logic extraction" is already done by using the external Vite plugin-legacy. The main concern for SvelteKit is to write a legacy-compatible code, while the legacy bundling is done by the external Vite plugin already.
That's not true about Vue 3, see Vue 3 Browser Compatibility.
Basically, the Vite plugin-legacy is a piece of code written by the same guys maintaining Vue, so the same logic, however in a fancier more universal form, is being offered by Vite plugin-legacy.
SvelteKit has an advantage over Vue that it's specific only to the Vite bundler, so we can leverage the hard work that done by the Vite plugin-legacy, we just need to "read" its results correctly, and this is basically what my PR is doing(plus many tests and etc.).
Totally agree!
The philosophy of "modern" legacy support is to not distinguish the legacy browsers in the HTTP request level, but on the client level instead, making it so simpler basically for everything (testing/debugging/caching/static-serving...). Thankfully, the solution in the client level is simple enough so you wouldn't naturally like to go to these places.
gamesguru commentedon Apr 19, 2023
@Tal500 Do you have it in the npm registry? As long as it's merged within the last few versions, I don't need the latest. Do we still need the legacy adapter if we're going to use this?
Other than that, I would try out Sapper I guess.
madkarlsson commentedon Jul 21, 2023
@gamesguru
Sapper is deprecated and should not be an alternative or a solution for anything at this point
https://sapper.svelte.dev/docs
Revert "add polyfil for old safary browsers"
Tal500 commentedon Aug 25, 2023
Sorry for the long wait, but I think I cannot keep update every time a new kit conflict occurs.
I'll be glad if anyone could help me keep update the versioning, since I don't have time for this side project for now.
nmnmcc commentedon Oct 1, 2023
cyanerd commentedon Oct 13, 2025
Nic-Polumeyv commentedon Jul 17, 2026
Kit 3 requires Svelte 5 (
svelte: ^5.56peer), and Svelte 5's client runtime is built onProxy($stateobjects, rest/spread props), which can't be transpiled and only partially polyfilled. So a legacy differential build of a current Kit app isn't possible even via the plugin route discussed above. I think this can be closed.Rich-Harris commentedon Jul 29, 2026
Agree