Feature Request: babel-preset-gatsby additional settings

[Undistraction]

Summary

It would be very useful to be able to override:

1. Which browsers are polyfilled when running in development (for example to allow IE11 to be tested when running gatsby develop.
2. Which strategy to use in Polyfilling (usage vs entry). When using third part modules that require polyfilling, Gatsby will not apply the polyfills they need. Switching to entry would allow third party modules to be covered.

Basic example

It currently exposes only a targets setting. It could add additional developmentTargets and babelEnvStrategy settings.

Motivation

Currently to change these settings you need to copy the whole of Gatsby's babel config and edit. IMHO it would make more sense to expose these settings as an API for the plugin.

[DSchau]

Which browsers are polyfilled when running in development

I'm not sure this needs to live in babel-preset-env. One really important note here is that we generally want to keep development and build as unified as possible. If we include something in development that is not included in production, I could see that leading to bugs just as frequently as not including polyfills at all.

That being said--development should work in IE 11, so if it doesn't--let's fix that!

Which strategy to use in Polyfilling (usage vs entry). When using third part modules that require polyfilling, Gatsby will not apply the polyfills they need. Switching to entry would allow third party modules to be covered.

This probably makes sense as a quick remediation and exposing an option (defaulted to current behavior of usage). Something like (in your app) with .babelrc.js

module.exports = {
  presets: [
    ['babel-preset-gatsby', {
      useBuiltIns: 'entry'
    }]
  ]
}

Would need to validate that these changes don't cause issues in any current flow while also providing a feasible alternative for users with requirements of supporting browsers like IE 11.

[Undistraction]

Thanks. As I mention in my reply to #12399 I think Gatsby already treats development differently from prodution. From the docs for babel-preset-gatsby:

targets
{ [string]: number | string }, defaults to { "browsers": ["last 4 versions", "safari >= 7", "ie >= 9"] } in production and { "browsers": ["last 2 versions", "not ie <= 11", "not android 4.4.3"] } in development when targeting the browser and { "node": 6 } in production and { "node": "current" } in development when targeting Node.js.

My understanding of this is that in production, the browser range is:

{ "browsers": ["last 4 versions", "safari >= 7", "ie >= 9"] }

But in development it is:

{ "browsers": ["last 2 versions", "not ie <= 11", "not android 4.4.3"] }

So unless I'm misunderstanding the docs, this problem can be fixed by using the same browser range for both cases (at least in userland).

[DSchau]

Well - let's not make changes quite yet!

Are there issues with development in IE 11? I think I asked that in #12399, but not sure that was ever answered!

In other words, can you develop your app in develop mode in IE 11?

[Undistraction]

@DSchau

In other words, can you develop your app in develop mode in IE 11?

Only if I:

1. override Gatsby's babel config and set babel-preset-env to use entry
2. Add babel-polyfill.

I've just done some tests with Gatsby's default starter (available here). Contrary to the docs it seems that Gatsby does Polyfill for IE11 in development and I could use Array.find in components/header.js without issue when running gatsby develop.

I then installed yup and used it within the starter. This immediately raises an error:

Object doesn't support property or method 'from'

Which originates from within commons.js, from a library called topsort which is a dependency of yup.

This means that:

1. Gatsby does polyfill userland code for IE11 when running gatsby-develop
2. Gatsby isn't polyfilling node_modules (as we have previously discussed).
3. Even if Gatsby happens to be applying polyfills that are expected by node_modules (in this case polyfilling Array.find), they are not available to these modules at runtime, possibly due to load order.

To illustrate 2, this is the code I added inside header.js:

import React from "react"

import * as Yup from "yup"

export const SCHEMA = Yup.object().shape({
  example: Yup.string(),
})

const Header = ({ siteTitle }) => {
  const a = ["a", "b", "c"]
  console.log("Found", a.find(e => e === "b", a)) // This logs successfully if yup isn't imported or referenced
  console.log("Schema", SCHEMA) 

...

[Undistraction]

@DSchau I've added a writeup as to how I got things working in #12399.

In terms of improving things I think it would be great if babel-preset-gatsby exposed:

• useBuiltIns so that a developer can opt to use entry instead of usage.
• debug so that a developer can clearly see what polyfills and transforms are being applied.

I'd be happy to put a PR together adding these two config params.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

Thanks again for being part of the Gatsby community!

[Undistraction]

So I think this is the rub:

Exposing entry as an option will only work effectively if Gatsby adds an import for babel-polyfill itself at a point in the lifecycle prior to the imports from any other plugins being parsed to ensure all client-side code (whether local to the project or applied by a plugin) is already polyfilled.

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[Undistraction]

Still an issue so reopening.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!