Svelte 5: Doesn't work on iOS 15.0 #10438
Comments
|
Unlike in #10069, this is for runtime code that we're shipping as part of the library. I do think that it would be nice to not use this API if there aren't performance issues in doing so - because polyfilling APIs is less straightforward to configure than transpiling language features. |
|
Are you suggesting to have the whole app be transpired and that the runtime isn't? This is a new project and unfortunately this is a blocker and I can't spend too much time trying to polyfill manually. We're deep in runes too so a migration will be rough |
|
I'm saying that transpilation (like that you can configure via Vite) won't help with API things like |
|
Got it. Yes, I agree. It's not an archaic version by any means and I base it off another products' revenue against various browsers which led me to testing our app and finding this out. |
|
Support is only good as of very recently so I would be in favor of avoiding this method in the runtime (or apply a polyfill ourselves). I'm wondering how we can avoid these kinds of accidental breakages in general. |
|
@dummdidumm ill try the pollyfill later and report back. Will have to run e2e tests against BrowserStack or lambdatest. Any regression like this can be detrimental. I found this when starting to set up integration tests and was instantly blocked. I wonder if there is a simple tool to scan a build and just tell you support, though full e2e tests is safer. |
|
@dummdidumm Polyfill fixes it. Looks like I'm not really a fan of having to bring in polyfills for decently modern browsers only because then you'll have to draw the line somewhere. This case, an "at" polyfill isn't that large, but not sure about other things. Have to weigh the pros vs cons. |
|
Yeah, as mentioned, we think it does make sense for the Svelte runtime to avoid using |
I think in eslint you can specify an EcmaScript version so it will flag any use of newer browser APIs for you |
|
I looked into how to more generally prevent this from happening, and the only way is to adjust the tsconfig - sadly, we can't prevent node globals from being loaded, so |
|
Can eslint be configured and be loose with compiler? Having more coverage than just .at would be nice. I saw a comment from @Rich-Harris about usage of at in compiler is fine. Plus it's used everywhere. Whatever way can achieve and guarantee regression would be ideal. |
|
as I understand 15.3 released more than 2 years ago, is it still popular? 15.4 already support it. |
A small chunk of revenue still comes through for 15.3 |
Regardless, it's kind of a regression to 4.0 |
Polyfill works though, so not really a huge deal. |
- check that the runtime doesn't use methods that are too new - add linting rule to prevent references to the compiler in the runtime (this is important for the first check, else the ambient node typings would be included, which includes a definition for `at()`, which means we no longer would get errors when violating the "don't use new methods" rule in the runtime) - fix code as a result of these new checks closes #10438
- check that the runtime doesn't use methods that are too new - add linting rule to prevent references to the compiler in the runtime (this is important for the first check, else the ambient node typings would be included, which includes a definition for `at()`, which means we no longer would get errors when violating the "don't use new methods" rule in the runtime) - fix code as a result of these new checks closes #10438
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
I tried to render a simple "Hello" world with Svelte 5 using SvelteKit on iOS 15.0 and page is blank and get a hydration error:
I also tried using Astro to not just blame SvelteKit and still get the error:
Reproduction
Open Svelte 5 app (develop & preview) on an iPhone 6s on iOS 15 Simulator and open page
Logs
No response
System Info
Severity
blocking an upgrade
The text was updated successfully, but these errors were encountered: