Gatsby: Adding a polyfill for ES6 Array.from()

[lloydh]

I need IE11 compatibility for a website but am getting errors from ES6 Array.from() used by emotion's createEmotion constructor.

Given gatsby supports the same browser targets as React I assumed the default config would handle this however I'm now trying to polyfill Array.from() specifically.

Looking for the correct way to polyfill gatsby I found 2177 and 3314 but not a clearly recommended approach.

I've tried importing core-js and polyfilling in an onClientEntry hook within gatsby-browser.js but it seems that createEmotion might be executing before the polyfill.

Help much appreciated.

Environment

Gatsby version: 1.9.192
Node.js version: 9.5.0
Operating System: OS X 10.13.3

[m-allanson]

This isn't a fix, but for context it looks like you're running into #3780.

[lloydh]

@m-allanson yup, looks like that's the problem.

It sounds like ES6 transpilling/minification is being looked at for gatsby 2 but in the meantime is polyfilling still my best bet, and if so where's the best place to do it?

[m-allanson]

@lloydh I think just adding import 'babel-polyfill to the top of your gatsby-browser.js should do it. Have a look at this thread / comment for more info.

Feel free to drop another note here if that doesn't work out.

[lloydh]

Thanks but I get the same result from babel-polyfill as with core-js — IE11 throws on emotion's ES6 methods before any code in my gatsby-browser.js runs.

This is gatsby-plugin-emotion's gatsby-browser.js which it looks like is getting first dibs:

/* globals window */
import { hydrate } from "emotion"

exports.onClientEntry = () => {
  if (
    typeof window !== `undefined` &&
    typeof window.__EMOTION_CRITICAL_CSS_IDS__ !== `undefined`
  ) {
    hydrate(window.__EMOTION_CRITICAL_CSS_IDS__)
  }
}

Polyfills need to be ahead of this.

[lloydh]

I solved my polyfill problem by creating gatsby-plugin-core-js.

Adding this as the first plugin in gatsby-config.js ensures the polyfill is executed before other plugin code utilising unsupported ES features.

[fk]

Nice @lloydh! Would love to see your plugin added to the list of Community Plugins!

[lloydh]

@fk that was the first place I looked so I'm happy if it can save other users from headaches!

Honestly I still don't know if this is the most idiomatic way of polyfilling gatsby but gatsyby-plugin-core-js allowed me to ship!

[grgur]

I don't recommend bloating your codebase with the entire core-js. If all you need is Array.from then add core-js as a dependency (npm i core-js) and require parts you need.

One way of doing that would be from gatsby-browser.js

exports.onClientEntry = () => {
  require('core-js/fn/array/from');
};

[lloydh]

@grgur thanks for the recommendation but using the .onClientEntry hook was my first attempt.

The problem is that gatsby-plugin-emotion is using Array.from in .onClientEntry and plugins run before anything in gatsby-browser.js can.

I agree about selectively importing features to polyfill but a better goal is having this all taken care of at build based on the browser targets.

[KyleAMathews]

FWIW, Gatsby v2 will take advantage of Babel 7's new auto-polyfilling which will handle problems like this more elegantly https://github.com/gatsbyjs/gatsby/blob/v2/docs/docs/browser-support.md#polyfills

[robwierzbowski]

@KyleAMathews Somewhat of a hijack of this issue -- I don't want to add a new issue without some new information.

Will it be possible to turn off auto-polyfilling for all browser code in 2.x? We use Financial Time's Polyfill.io to only serve polyfills to browsers that need them. It's a good performance strategy for smaller file sizes, less JS processing, and more native code usage.

[KyleAMathews]

@robwierzbowski yeah, we could add that — though the new method might be faster for y'all. Especially if we can get two JS builds working — one targeted at newer browsers and one targeted at older browsers.

[robwierzbowski]

In my experience serving minimal polyfill code per UA string is fastest, especially when serving a wide range of browser capabilities. No code to the browsers that don’t need it.

Allowing a user to choose their polyfill strategy (useBuiltIns, runtime, or external) is probably the safest option for wide developer happiness, as each comes with their own considerations for perf, complexity, and stability. It’s my experience these can be real sticking points for a team.

[robwierzbowski]

Thanks for responding so quickly!

[vai0]

After updating to v2, imported 3rd-party modules i.e., react-slick that rely on Array.from don't seem to be polyfilled 😞. Does gatsby support polyfilling 3rd party modules? I'm running v2.0.52.

[Dogtiti]

@vai0 same issue, I use the react-slick too. And it doesn't support IE9, so have you found some ways to solve it?

[vai0]

@Dogtiti I ended up using this: https://www.gatsbyjs.org/packages/gatsby-plugin-polyfill-io/

[Dogtiti]

@vai0 ok, thanks I'll try