chore: Add custom browserslist

[cmaddox5]

Now that we have an idea what browsers our vendors use, we can add a browserslist config to help catch incompatibilities. I added this to ESLint and StyleLint so CI can help us find issues.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1207719326862934

[digitalcora]

If we ignore something we should probably add a note explaining why. I assume it's because the only places we use this feature are on screen types that actually do support intrinsic-width?

[cmaddox5]

Before adding the correct Bus E-Ink version, this was the only error we needed to deal with and the browser it is an issue for doesn't reach the particular CSS in question. After the update, there's a 919 errors so adding global ignores isn't a good idea. I'm curious how best to handle this. At a webpack level, that seems as easy as separating out the apps into their own entries and specifically calling out the browser each entry will use. I'm not sure about the linters though...

[digitalcora]

Hm... is this warning us about using features that Babel will ultimately compile down to something that does actually work? Or are those warnings truly about features that can't be supported automatically?

[cmaddox5]

The latter. And they tell us which particular browser it has an issue on. That's how I know the errors don't apply to the particular browser running the code. So for example, after adding Chrome 45 (Bus E-Ink) and Firefox 90 (Sectional) we get errors in Pre-Fare specific CSS files. I believe these checks are also happening with no knowledge of the babel config so I'm not sure if it's possible to make it work on a per-screen type basis. Gonna do some more reading.

[digitalcora]

Follow-up question for investigation, does the Webpack build itself throw an error or warning when we use a feature Babel can't transpile to the target browsers, or does it silently allow such features?

[digitalcora]

Oh, right, if these are CSS issues then I suppose Babel wouldn't be doing anything about them. We'd need something like postcss-preset-env in our pipeline to transpile CSS features.

I wonder if we should split stylesheet compatibility into a separate task here. We're already pretty sure there are no issues with the CSS we have now, so it perhaps shouldn't be considered a requirement of this task, which is getting us better JS compatibility so we can upgrade libraries.

[cmaddox5]

Yeah that sounds good. Will remove those and create a task.

[cmaddox5]

I'm curious if we should do the same with ESLint. The lint errors showing up right now are either false positives or handled by the polyfills we are already importing that ESLint has no knowledge of.

[digitalcora]

Interesting. I would have expected the opposite based on this thread, which warns that the ESLint plugin is too lenient in assuming which polyfills are available (suggesting there is some interaction with Babel).

[cmaddox5]

I may have just configured the plugin incorrectly (documentation is lackluster unfortunately). I made an adjustment and the errors are gone. I found in the source code for the plugin that it assumes polyfills are done in babel based on the presence of a babel config file. We didn't have one so I made it. Hopefully this doesn't mean I just silenced the errors by accident.

[digitalcora]

I don't see a change to our Webpack config file here; we have this in there:

["@babel/preset-env", { targets: "> 0.25%" }]

I assume we can now at least remove the targets configuration here and let browserslist take care of it — does present-env read that by default?

[cmaddox5]

I don't see a change to our Webpack config file here; we have this in there:

["@babel/preset-env", { targets: "> 0.25%" }]

I assume we can now at least remove the targets configuration here and let browserslist take care of it — does present-env read that by default?

Woops, thank you. And yes, preset-env would pick it up by default.

[digitalcora]

One small comment. I do like how it's possible to pull out the Babel config like this, simplifies the main Webpack config structure.

[digitalcora]

This is invalid JSON, though I guess Babel allows it? "Oldest browsers possible" def isn't accurate with how this is set up, so I think we should delete.