Gatsby: Browserlist definition changes not reflected in builds

[askibinski]

Description

I experienced weird behaviour when using polyfills with browserlist, which I tried to verify as stackoverlow question with answer before posting an issue here.

It feels like a bug but maybe someone with more in depth knowledge on the inner workings with babel-presets-env can confirm or deny this?

Steps to reproduce

1. Checkout https://github.com/askibinski/browserlist-ie11-demo
2. gatsby build && gatsby serve
3. Verify dat the polyfills for find() and Object.values() are available in de app-#####.js file (see index page where they are used in runtime).

Correct so far because we define [">0.25%", "not dead"] in the package.json which is also the Gatsby default and provides polyfills for these ES6 methods (for IE11 etc).

1. Change the browserlist definition in package.json to ["last 2 Chrome versions"].
2. gatsby clean
3. gatsby build && gatsby serve

Expected result

The polyfills should not be used anymore, since we only target the last 2 versions of chrome.

Actual result

Unexpected: app-#####.js still contains the polyfills. However if you completely remove node_modules folder and perform a new production build (after npm i) the polyfills are gone.

Environment

  System:
    OS: Linux 5.3 Ubuntu 19.10 (Eoan Ermine)
    CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Shell: 5.0.3 - /bin/bash
  Binaries:
    Node: 11.15.0 - /usr/local/bin/node
    Yarn: 1.21.1 - /usr/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm
  Languages:
    Python: 2.7.17 - /usr/bin/python
  Browsers:
    Firefox: 72.0.2
  npmPackages:
    gatsby: ^2.19.7 => 2.19.7
    gatsby-image: ^2.2.39 => 2.2.39
    gatsby-plugin-manifest: ^2.2.39 => 2.2.39
    gatsby-plugin-offline: ^3.0.32 => 3.0.32
    gatsby-plugin-react-helmet: ^3.1.21 => 3.1.21
    gatsby-plugin-sharp: ^2.4.3 => 2.4.3
    gatsby-source-filesystem: ^2.1.46 => 2.1.46
    gatsby-transformer-sharp: ^2.3.13 => 2.3.13
  npmGlobalPackages:
    gatsby-cli: 2.8.29

[PolGuixe]

Experiencing a similar issue.

[vpicone]

Same, bundle size is effectively identical whether you're using the very conservative gatsby default, browserlist default, latest 1 version, or latest chrome version (just Chrome 80)

[github-actions[bot]]

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! 💪💜

[wardpeet]

Fixing polyfills is going to be handled in a week or 2, hopefully you can wait this long. Thanks for the bug report!

[vpicone]

Nice! Thanks @wardpeet. Wondering how long every Gatsby project has just been getting the defaults haha.

[askibinski]

@wardpeet Thanks, are there any related issues I can find about that?

[mmclafferty]

Any update on this? Experiencing the same thing.

[pindjur]

deleting node_modules/.cache worked before but now its not working still getting default polyfils, will try removing whole node_modules.

[wardpeet]

Is this still happening from [email protected] a gatsby clean should clean up all caches like babel, browserlist, ....

I'll be closing this in a few days if I don't hear back from anyone. Thank you!

[visualfanatic]

It still does not do it, I am using 2.24.43 and had to use the BROWSERSLIST_DISABLE_CACHE env var.

For others looking for a solution:

BROWSERSLIST_DISABLE_CACHE=true yarn build

[gustaflindqvist]

We have the same problem. Doesn't see any changes.

Going the test setting the env before build command to disable the cache manually.

[wardpeet]

If you do gatsby clean, it removes all the caches and a gatsby build uses .browserlistrc, browserlist or browserlist in package.json.

It's not ideal but at least it's a workaround