-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differential legacy builds #12
Comments
This comment has been minimized.
This comment has been minimized.
Unverified assumption: https://github.com/vitejs/vite/tree/main/packages/plugin-legacy might help here. |
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. This has come up in a few tickets in Sapper and most recently here: Relates to #93 |
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! |
+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. 😢) |
Is there any update or plan for this? This is a deal breaker for me and preventing me from migrating over from sapper because I need to target a platform that does not support native ESM. I tried using |
I was able to get |
I've managed to make it work in IE11 with @vitejs/plugin-legacy and staticAdapter by adding necessary polyfills by hand ('custom-event-polyfill' , 'core-js/modules/es.promise.js', 'regenerator-runtime/runtime') but the biggest problem is that you will need to add some code to each html file with legacy build scripts, like this <script nomodule="" src="/_app/assets/polyfills-legacy.[hash].js"></script>
<script nomodule="">
System.import("/_app/start-legacy-[hash].js").then(function(mod) {
mod.start({ // all options was taken from code generated by sveltekit in type="module" script
target: document.querySelector("#svelte"),
paths: {"base":"","assets":""},
session: {},
host: location.host,
route: true,
spa: false,
trailing_slash: "never",
hydrate: {
status: 200,
error: null,
nodes: [
System.import("/_app/layout.svelte-legacy-[hash].js"), // "import" call changed to System.import in order to work in old browsers
System.import("/_app/pages/about.svelte-legacy-[hash]js")
],
page: {
host: location.host, // TODO this is redundant
path: "\u002Fabout",
query: new URLSearchParams(""),
params: {}
}
}
});
})
</script> I was trying to understand how to make sveltekit generate such a code to be added to %svelte.body% but didn't make it. Will try to look at this in near future, if I will have time. Update: I've managed to monkey-patch (under monkey-patching I mean that I just added some functions and data here and there and it just works) |
@smertelny I've been working on something similar and was falling at the last hurdle (i.e. calling the client |
I can confirm I have the same error, the path is malformed there after using the legacy plugin. |
Finally I had some time to look into it (again). But there is another problem for implementing legacy build and it is a module that is inlined into page with start and set_public_env function in it. |
We need this fixed same thing is happening to me too, no |
Looks like this issue is tagged as post-1.0. Since it is the one issue which blocks me (and others) from using Sveltekit in projects, I would like to suggest to move it to 1.0 tag, like it used to be. @Rich-Harris ? Is it definitely out of scope? Sveltekit is a great candidate when developing apps for low-performant devices, since it is less demanding in runtime than most other frameworks. However, those low-performant devices usually require legacy support, and that's the blocker. |
I'm glad to announce that I had managed to fix this problem on my fork (which is a continuation of PR #2745 by @smertelny). The reason for the manifest problem is that Vite generates the manifest only after all Rollup build outputs end, as we can see in the internal Vite manifest plugin, in the Vite-Legacy plugin modifies Rollup output to be an array in size of at least two, one for the legacy version and the other targets for the original: So in a similar fashion to the internal manifest plugin, I had modified the This took me so much time to investigate, I had to make my own version of the vite-legacy and the manifest plugin until I had found this logic. (Why does Vite documentation can't be better and in more details???)
I totally agree. I think that beside the time for implementation, Rich is concerned about the stability of the API for 1.0. |
I'm glad to share my work - PR #6265, solving this issue. Please test locally in your legacy browsers and share your experience, I have only tested it on IE11. |
@vitejs/plugin-legacy was updated to 2.0.1 |
Yes, the demos on my PR #6265 are using it! Thought I'm not sure the update made a difference. |
Same err with @vitejs/plugin-legacy and manifest.json |
Any updates? Using latest sveltekit with node-adapter with 3.0.1 legacy plugin and still get this error, that vite_manifest.json is not found in .svelte-kit/output/server/vite-manifest.json
|
@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. |
@Rich-Harris please take a look at the PR #6265 from @Tal500 we need this feature in SvelteKit 👍 |
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 It has been pointed out that Edit: Looks like |
Sadly, that's what I'm doing currently, while still hoping for a solution from the core team.
That's not true about Vue 3, see Vue 3 Browser Compatibility.
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. |
@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. |
Sapper is deprecated and should not be an alternative or a solution for anything at this point https://sapper.svelte.dev/docs
|
Because plugin/legacy doesn't work correctly with sveltekit: sveltejs/kit#12 This reverts commit 85acd5a.
Sorry for the long wait, but I think I cannot keep update every time a new kit conflict occurs. |
Any updates? . . . |
Not yet sure what this looks like
The text was updated successfully, but these errors were encountered: