Skip to content

Simplify eslint configs, modernize eslint config for docsJS#42270

Open
mdo wants to merge 1 commit intov6-devfrom
v6-js-tweaks
Open

Simplify eslint configs, modernize eslint config for docsJS#42270
mdo wants to merge 1 commit intov6-devfrom
v6-js-tweaks

Conversation

@mdo
Copy link
Copy Markdown
Member

@mdo mdo commented Apr 4, 2026

  • Replace [].concat(...), Array.from(), and .split('') with the spread operator ([...iterable]) across source, tests, and site files. Where we're just iterating (not building an array), use for...of directly instead.
  • Replace arr[arr.length - 1] with .at(-1) in a handful of places.
  • Enable unicorn/prefer-spread and unicorn/prefer-at as errors so we enforce these going forward.
  • Drop the ecmaVersion: 2019 and 2020 overrides for site files—our browser targets (Chrome 120+, Firefox 121+, Safari 15.6+) support well beyond that, so we just use latest everywhere now.
  • Delete the legacy .eslintrc.json since we use ESLint 10's flat config exclusively. It was unused and drifting out of sync.

@mdo mdo requested a review from a team as a code owner April 4, 2026 05:05
@mdo mdo added this to v6.0.0 Apr 4, 2026
@github-project-automation github-project-automation bot moved this to Inbox in v6.0.0 Apr 4, 2026
},
sourceType: 'script',
parserOptions: {
ecmaVersion: 2019
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't just use latest. What is latest now, won't be the same latest later and so on... IMHO we should just stop having hardcoded browser versions in .browserslistrc and just support latest. Then, this change would be OK too and we could drop babel and co altogether.

Copy link
Copy Markdown
Contributor

@alpadev alpadev Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be fair our browserslist is outdated anyway or should I say incompatible with the CSS features we use in v6 (and maybe even v5 to some extent).

While Babel handles transpiling/polyfilling our JS, not sure about the CSS. I know we have autoprefixer in place but that handles only vendor prefixes not any sort of workarounds or polyfills. (Maybe postcss does?)

I wanted to open a discussion about this already, but due lack of time (as usual 😔) I wasn't able to, yet. I meant to propose to maybe use some baseline definition e.g. baseline widely available (see https://github.com/browserslist/browserslist?tab=readme-ov-file#queries). To read more about baseline in general you may want to check out https://web-platform-dx.github.io/web-features/. Besides that MDN or CanIUse shows the baseline support too, so I'd say it's already something that is well adopted.

Image Image

Also I already locally tested some stylelint plugins to check if we use CSS that matches the browsers we wanted to support.

Those three I tried been stylelint-no-unsupported-browser-features, stylelint-browser-compat and stylelint-plugin-use-baseline.

There are pros and cons to all of them - stylelint-no-unsupported-browser-features and stylelint-browser-compat are more verbose about browser incompatibility like showing versions that don't support a certain feature, on the other hand stylelint-plugin-use-baseline doesn't. It just tell you that a feature isn't available.

On the positive side stylelint-plugin-use-baseline is very configurable compared to the other two and it looks like it's the most consistent in finding unsupported properties/values.

Image

Eslint has support for baseline too: https://baselinejs.vercel.app/ or eslint-plugin-compat


Last but not least with our current browserslist we support 87.5% of global users (according to https://browsersl.ist/)

Image

While baseline widely available with downstream covers 89.3%

Image

Important

I have to mention that we use some CSS in v6 that isn't "widely available" yet because it's too new.

@mdo @XhmikosR thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Inbox

Development

Successfully merging this pull request may close these issues.

3 participants