svelte icon indicating copy to clipboard operation
svelte copied to clipboard

Svelte 5: Doesn't work on iOS 15.0

Open j opened this issue 1 year ago • 15 comments
trafficstars

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:

Screenshot 2024-02-08 at 4 22 46 PM

I also tried using Astro to not just blame SvelteKit and still get the error:

Screenshot 2024-02-08 at 4 38 22 PM

Reproduction

Open Svelte 5 app (develop & preview) on an iPhone 6s on iOS 15 Simulator and open page

Logs

No response

System Info

iPhone 6s on iOS 15 Simulator

Severity

blocking an upgrade

j avatar Feb 09 '24 00:02 j

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.

Conduitry avatar Feb 09 '24 00:02 Conduitry

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

j avatar Feb 09 '24 02:02 j

I'm saying that transpilation (like that you can configure via Vite) won't help with API things like Array.prototype.at. If you need your app to work on browsers without that method today, a polyfill for it is probably your best best. But I'm also saying that it does probably seem reasonable for Svelte's internal API to avoid using this, so that polyfilling it wouldn't be necessary.

Conduitry avatar Feb 09 '24 03:02 Conduitry

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.

j avatar Feb 09 '24 05:02 j

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. In the meantime, you can polyfill it something like this.

dummdidumm avatar Feb 09 '24 09:02 dummdidumm

@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.

j avatar Feb 09 '24 16:02 j

@dummdidumm Polyfill fixes it. Looks like at is called ~20x in my case.

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.

j avatar Feb 09 '24 20:02 j

Yeah, as mentioned, we think it does make sense for the Svelte runtime to avoid using Array.prototype.at. The polyfill on your end should only need to be temporary.

Conduitry avatar Feb 09 '24 21:02 Conduitry

I wonder if there is a simple tool to scan a build and just tell you support, though full e2e tests is safer.

I think in eslint you can specify an EcmaScript version so it will flag any use of newer browser APIs for you

gka avatar Feb 14 '24 06:02 gka

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 at would still be a false negative. We would also need to decide whether we want the same guarantees for the compiler or if it's ok if that one uses more current features and we for example shim them in the playground. Reopening until this is decided.

dummdidumm avatar Feb 27 '24 12:02 dummdidumm

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.

j avatar Feb 27 '24 15:02 j

as I understand 15.3 released more than 2 years ago, is it still popular? 15.4 already support it.

stalkerg avatar Apr 17 '24 05:04 stalkerg

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

j avatar Apr 17 '24 15:04 j

as I understand 15.3 released more than 2 years ago, is it still popular? 15.4 already support it.

Regardless, it's kind of a regression to 4.0

j avatar Apr 17 '24 15:04 j

as I understand 15.3 released more than 2 years ago, is it still popular? 15.4 already support it.

Polyfill works though, so not really a huge deal.

j avatar Apr 17 '24 15:04 j