Default browserslist should include Googlebot (Chrome 41)

[buildbreakdo]

Googlebot is based on Chrome 41 and should be included in the default browserslist in package.json:

...
  "browserslist": [
    ">0.2%",
    "not dead",
    "not ie <= 11",
    "not op_mini all"
  ]
...

Googlebot uses a web rendering service (WRS) that is based on Chrome 41 (M41). Generally, WRS supports the same web platform features and capabilities that the Chrome version it uses — for a full list refer to chromestatus.com, or use the compare function on caniuse.com.

Source: https://developers.google.com/search/docs/guides/rendering

[miraage]

I'm not sure if CRA apps are meant to be crawled

[buildbreakdo]

@miraage What has led to that conclusion / suspicion? Think for a web application being discoverable on the web is critical; otherwise expect that to be explicitly stated (e.g., use this for intranet applications).

[Bazzer588]

You can use 'Fetch as Google' to see how your site looks to Googlebot
https://www.google.com/webmasters/tools/googlebot-fetch-details

I've tried this on a site build with react-scripts and it looks fine

They are phasing this tool out, apparently the new one is
https://search.google.com/search-console

[buildbreakdo]

@Bazzer588 Ah, good to know that has changed. Upgraded to the latest tools a while back and had to downgrade because 'Fetch as Google' no longer worked.

May be true that out of the box 'Fetch as Google' works, however this may not be the case if code is added using some of the latest javascript features because it's not polyfilled down to Chrome 41.

[Bazzer588]

The new one works too - https://search.google.com/search-console - and it's actually better
My test site has to work with IE11, so the first line is
import 'react-app-polyfill/ie11';
...perhaps this makes a difference ?

browserlist is defined as

  "browserslist": [
    ">0.2%",
    "not dead",
    "not ie <= 10",
    "not op_mini all",
    "ie 11"
  ]

[mrmckeb]

Interesting. And thanks for the assistance @Bazzer588. Would someone like to create a PR for this?

If there aren't any major negative impacts, we should be able to merge this in.

[saranshkataria]

I can work on it

[ianschmitz]

See my comment over at #6345 (comment). We could change browserslist which affects our css loader, however the .js bundles already compile down to ie9.

[buildbreakdo]

@saranshkataria issue target was Chrome 41 (googlebot), Bazzer mentioned IE 11 because that was a requirement for his project. Sounds like from @ianschmitz comments in the pull request that IE11 is already covered by targeting down to IE9?

browserslist currently only affects the CSS output, but not the javascript. Currently javascript transpilation ignores browserslist and is forced to compile down to support ie9 as seen in our babel config.
via #6345 (comment)

Interesting to find out that browserslist is only for CSS and not JavaScript, opened the issue with the misunderstanding that browserslist affected JavaScript too. In light of that not being the case maybe this should be closed? How do we know which browsers CRA targets for JavaScript (maybe missed this in the documentation? Pretty sure it's not mentioned in the browserslist terminal dialog [that browserslist is only for CSS]).

Also curious about the value in targeting CSS to a particular browser version if the project does not target JavaScript at that version too. Could end up in a scenario where the CSS works and JavaScript does not. As is, if I'm understanding correctly, there is a floor on what browsers are supported based on what is configured for the JavaScript and browserslist should never target below what browsers are targeted for the JavaScript. Which leads me to the conclusion that browserslist should be internalized unless it also affects JavaScript too. However, since there seems to be a marked shift to more configurability and broader support, would think going the other way would be better and browserslist would affect both CSS && JavaScript (thinking out loud).

In a nutshell, CSS and JavaScript browser targeting should be the same. Does not make sense that one would work and the other would not.

[saranshkataria]

@buildbreakdo agreed that the same browserslist should be used for both of them. Also, I am not sure what CSS specific features change with browsers? @ianschmitz could you shed some light on that as well, please?

[esetnik]

This seems to be a duplicate or at least related to #6198. It looks like a lot of people (like me) are assuming that browserslist is affecting the javascript polyfills and not just css output. Someone actually already partly implemented this behavior in #5264.

[ianschmitz]

Closing this as browserslist now affects javascript output as of 3.0. Users can fine tune their supported browsers assuming they include the appropriate polyfills.