Align transpiling with babel & core-js future about sapper-ie HOT 13 CLOSED

I've started leveraging core-js a lot more recently, and I'm pretty happy with the results.

Once I get a minute I might try converting this repo to use core-js, I'm not really concerned about bundle size - I'm interested in only making the site work for IE11 users - I don't care how fast it is or how big it is or how nice it looks. If you use an obsolete browser you get an obsolete experience.

from sapper-ie.

@antony afraid not. I've found out last week with a new project that the default sapper template is actually pretty much OK in supporting IE11 and edge save a few polyfills (IIRC fetch and what's considered "default" on polyfill.io), so I haven't had the urgency (and time, sorry!) to look at the core-js options further and I don't know whether, if and/or when this becomes relevant again.

I did do some more digging though as to why these polyfills are needed in the first place and that's because of this "issue" with shimport: Rich-Harris/shimport#4. Shimport loads the sapper JS in which I haven't encountered any issues regarding IE11/Edge support yet (haven't used object-spread yet, so...).

Anyways, any polyfilling core-js would do happens after svelte's compilation. Adding core-js support in the babel-step would only make sense when you're a) using features you haven't already polyfilled (default; fetch) and/or b) when you're using features that svelte does not know how to handle. If we add in core-js like in my fork, the legacy bundles will always include all the polyfills needed by the browserslist, including the ones we already have with polyfill.io.

Long story short, I have my doubts as to whether core-js should be included in the sapper-ie-template by default, since it impacts bundle size quite a lot. Maybe a different branch, or different sapper template repo (sapper-ie-es2019-template) might make more sense.

Love to hear your thoughts on this!

from sapper-ie.

Got a fork with the above changes here: https://github.com/rombrom/sapper-ie

from sapper-ie.

@rombrom nice work! I'll give your fork a go and then maybe it would be worth opening a pull request?

from sapper-ie.

Cool! Let me know if you run into any issues.

from sapper-ie.

@rombrom you should use corejs: 3 option only in one place - preset-env OR runtime.

from sapper-ie.

@rombrom Tried it out in IE11 - and it works, it's nice :) Did you notice that this doesn't work on Edge any more though?

I've specifically put in a library which uses rest-spread, which Edge doesn't support. The non-legacy version requires rest-spread to be processed by Babel in order to support Edge.

from sapper-ie.

I see. That's too bad... I expected core-js to pick it up as well but alas. Any idea why Edge specifically needs the rest-spread babel plugin?

@zloirock, oh I didn't know. Combing through the core-js/babel info didn't make this apparent. I figured runtime-transforms would be separate from the preset-env polyfilling so it'd depend on your use-case. Do you know why only one of these options is necessary?

@antony What do you want to do with this issue? I might continue experimenting with some setup later this week, but since your version is already a perfect working example I guess this issue is reaaaly low priority and more along the lines of "nice-to-have".

from sapper-ie.

Since each of whose options for different ways of polyfilling and they conflict together.

from sapper-ie.

@rombrom It doesn't work in Edge because you aren't babelifying the non-legacy build. Edge uses the non-legacy build, but doesn't support rest-spread.

If yours provides smaller bundle-size, or faster compilation, and you can get it to work in Edge + IE11, then I'd happily take your changes, as it seems like it might be a cleaner solution.

from sapper-ie.

@zloirock thanks. I'm curious how these options differ concerning generated code.

@antony I don't think taking the core-js approach will result in smaller bundles or faster compilation. The only foreseeable advantage is developer experience since we can polyfill features based on usage and browserslist targets. Having no core-js would mean a 'bring-your-own-polyfill/babel-transform' kind-of situation.

Regardless, I've updated my fork. I'll try to take some time later this week to explore whether we can optimize build-time and bundle-size.

from sapper-ie.

@rombrom did you have any time to look at this? I'll try your updated fork soon and get back to you with results.

from sapper-ie.

It was already asked on Discord (by someone else and me) and StackOverflow, but is there a way to have an additional bundle, next to the client’s, server’s and service-worker’s?

In this bundle, the polyfills needed by shimport could be put together and inserted before the Sapper scripts, so there is no need to use polyfill.io—which I don’t want to rely on.

Another way could be putting them in a manualChunk which will cause them to be in a separate file. But there is no way of knowing the generated filename of this chunk in template.html, or is there?

And also thank you @antony and @rombrom for making me understand what is needed to get the site to work in older browsers!

from sapper-ie.