Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Eslint v9 Flat Config format #411

Open
skyclouds2001 opened this issue Apr 16, 2024 · 14 comments
Open

Support for Eslint v9 Flat Config format #411

skyclouds2001 opened this issue Apr 16, 2024 · 14 comments

Comments

@skyclouds2001
Copy link

skyclouds2001 commented Apr 16, 2024

Here's what I did

config as follows in eslint.config.js

// eslint.config.js
import standard from 'eslint-config-standard'

export default [
  standard,
  // ...
]

this will report:

ConfigError: Config (unnamed): Key "parserOptions": This appears to be in eslintrc format rather than flat config format.

What I expected to happen

should use as above without reporting error

What seems to have happened

it seems that currently eslint-config-standard does not support for flat config format, is there any plan to migrate to flat config format in the future?

@skyclouds2001
Copy link
Author

I read https://eslint.org/docs/latest/use/configure/migration-guide#using-eslintrc-configs-in-flat-config and confirmed this way can resolve this issue at present:

import path from 'node:path'
import url from 'node:url'
import { FlatCompat } from '@eslint/eslintrc'

export default [
  ...(new FlatCompat({
    baseDirectory: path.dirname(url.fileURLToPath(import.meta.url)),
  }).extends('eslint-config-standard')),
  // ...
]

@skyclouds2001
Copy link
Author

skyclouds2001 commented Apr 22, 2024

another solution is:

import path from 'node:path'
import url from 'node:url'
import { FlatCompat } from '@eslint/eslintrc'

export default [
  ...(new FlatCompat({
    baseDirectory: path.dirname(url.fileURLToPath(import.meta.url)),
  }).config({
    extends: [
      'eslint-config-standard',
    ],
  })),
  // ...
]

@53v3n3d4
Copy link

This also works

import { FlatCompat } from '@eslint/eslintrc'

const compat = new FlatCompat()

export default [
  // standard,
  ...compat.extends('eslint-config-standard'),

@donalmurtagh
Copy link

donalmurtagh commented May 14, 2024

This worked for me

import { FlatCompat } from '@eslint/eslintrc'
import { fixupConfigRules } from '@eslint/compat'

const compat = new FlatCompat()

export default [
  ...fixupConfigRules(
    compat.config({
      extends: ['standard']
    })
  )

  // other config objects
]

@Mtillmann
Copy link

Thanks for the solutions. Am I going insane or is eslint completely pointless without support for this package?

@ZelnickB
Copy link

ZelnickB commented May 26, 2024

It's weird that this is an issue since the README quite literally says that:

This package exports a flat ESLint configuration.

@voxpelli
Copy link
Member

@ZelnickB The code in the current repo is not released

@pjg
Copy link

pjg commented May 30, 2024

@voxpelli could you please release a version with support for the flat eslint config file? It can be a pre-release too, as that also helps.

@voxpelli
Copy link
Member

@pjg As mentioned in standard/standard#1948 (comment) an alternative version has been released.

Besides that, I do not know what state the current repository is in as it was modified without my involvement

@skyclouds2001
Copy link
Author

Now though the documentation indicates that this repo has supported ESLint flag config, but in fact, this still existed some issues

@whaaaley
Copy link

whaaaley commented Oct 24, 2024

Simply importing packages like FlatCompat or neostandard, not even calling them, completely break vscode eslint extension. We're all in an impossible situation right now for literally 50 lines of code in a config file. Please fix this.

@voxpelli
Copy link
Member

@whaaaley neostandard works perfectly with the ESLint extension, and if I wouldn’t be able to make it work there then I for sure wouldn’t be able to make it work here either.

Unless you created an issue about this in neostandard today that I haven’t seen, then this is not something that has been reported to me/us over there.

I myself use the ESLint VS Code extension all the time and with great success, and one of the primary design goals of neostandard was to avoid having to create dedicated extensions, as was needed by standard

@Mtillmann
Copy link

@voxpelli would you mind sharing your setup? I have been watching this issue for a long time and I also still have issues getting with vscode. Thanks a lot

@voxpelli
Copy link
Member

@Mtillmann I don’t want to hijack this thread too much, questions regarding https://github.com/neostandard/neostandard and its setup I’ll answer there, it’s essentially standard for ESLint 9 with an open governance

Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Nov 14, 2024
I happened to hit upon one of the previous issues we'd come across when considering how we could get ESLint and StandardJS to work together. [Support for Eslint v9 Flat Config format](standard/eslint-config-standard#411) was one of the blockers that meant to have both ESLint and StandardJS play ball, we were stuck on ESLint v8.

I spotted that there had been some [recent activity](standard/eslint-config-standard#411 (comment)), all of which referenced an alternative called 'neostandard'.

And oh my! All my issues/dreams were answered

- Built for ESlint to avoid the need for separate IDE tooling
- Built for the latest ESLint (v9) so flat-file config is supported
- Just like we did, any style rules have been updated to use @stylistic/eslint-plugin
- A desire to work with current practices. So, banning or requiring ; is an option, along with disabling style rules for those opting to use prettier

For context, maintenance on StandardJS and related packages like eslint-config-standard has been stalled for some time. neostandard references the issue as being a [block in governance and direction of travel](standard/standard#1948). I've not been through every message, but it appears the maintainers are split between those who remained committed to StandardJS's 'one-tool one way' approach and those looking to move to where most folks are: ESLint.

Even our own @johnwatson484 [has gotten involved!](standard/standard#1948 (comment))

The thread suggests that those behind StandardJS are open to reconciling the neostandard fork with StandardJS. But that comment was made some time ago. My bet is neostandard is here to stay as the successor to StandardJS.

So, this change strips out all my hand-cranked implementations of the StandardJS rules, including those it was implementing from other plugins and replaces them with neostandard.

Lovely!
Cruikshanks added a commit to DEFRA/water-abstraction-system that referenced this issue Nov 22, 2024
I happened to hit upon one of the previous issues we'd come across when considering how we could get ESLint and StandardJS to work together. [Support for Eslint v9 Flat Config format](standard/eslint-config-standard#411) was one of the blockers that meant to have both ESLint and StandardJS play ball, we were stuck on ESLint v8.

I spotted that there had been some [recent activity](standard/eslint-config-standard#411 (comment)), all of which referenced an alternative called 'neostandard'.

And oh my! All my issues/dreams were answered

- Built for ESlint to avoid the need for separate IDE tooling
- Built for the latest ESLint (v9) so flat-file config is supported
- Just like we did, any style rules have been updated to use @stylistic/eslint-plugin
- A desire to work with current practices. So, banning or requiring ; is an option, along with disabling style rules for those opting to use prettier

For context, maintenance on StandardJS and related packages like eslint-config-standard has been stalled for some time. neostandard references the issue as being a [block in governance and direction of travel](standard/standard#1948). I've not been through every message, but it appears the maintainers are split between those who remained committed to StandardJS's 'one-tool one way' approach and those looking to move to where most folks are: ESLint.

Even our own @johnwatson484 [has gotten involved!](standard/standard#1948 (comment))

The thread suggests that those behind StandardJS are open to reconciling the neostandard fork with StandardJS. But that comment was made some time ago. My bet is neostandard is here to stay as the successor to StandardJS.

So, this change strips out all my hand-cranked implementations of the StandardJS rules, including those it was implementing from other plugins and replaces them with neostandard.

Lovely!
Cruikshanks pushed a commit to DEFRA/water-abstraction-system that referenced this issue Nov 22, 2024
DEFRA/water-abstraction-team#115

Now, we are a team of seven, with seven different opinions on the 'right' way to write the code! Because of our size, we are splitting into two teams to focus on various features simultaneously. But we'll still be working with the one code base.

We'd already moved from just using [StandardJS](https://standardjs.com/) to lint our code to using **StandardJS** via **ESLint** (we kept the rules but not the tool) because there are too many cases where **StandardJS** has no ruling, but we wanted one.

However, each time these rules don't provide a style convention, the team must stop, discuss, debate, and finally decide how something will be done. We want something else to take the decision away from us!

Step forward [Prettier](https://prettier.io/). **Prettier** is an opinionated code formatter that focuses only on the style of the code.

> Prettier enforces a consistent code style (i.e. code formatting that won’t affect the AST) across your entire codebase because it disregards the original styling by parsing it away and re-printing the parsed AST with its own rules that take the maximum line length into account, wrapping code when necessary.

So, any rules or conventions we have that would affect the [Abstract Syntax Tree (AST)](https://www.nearform.com/insights/what-is-an-abstract-syntax-tree/) would still be controlled by **ESlint**. These are the things as a team it is worth spending time debating and agreeing.

For the rest, we intend to let **Prettier** take over. It is widely used across the JavScript community and is popularly advocated for teams that become large or dispersed like ours.

Our approach to the adoption was first to remove our existing **ESlint** config, add **Prettier**, and then let it update all the files.

Then, having checked through as a team there were no 'red-line' changes, commit them. We then add **ESlint** back in and only re-apply the non-stylistic rules.

Our research found that JSDoc is still better managed through **ESlint** (**Prettier** does nothing with it), so we also added our original config for that.

Another fundamental change is that we are no longer bringing in **StandardJS** as an **ESlint** extension. This means we can move to the latest **ESlint** v9 and away from the [deprecated config file format](https://eslint.org/docs/latest/use/configure/configuration-files-deprecated) to the new [flat file config](https://eslint.org/docs/latest/use/configure/configuration-files).

Previously, we'd been blocked because extensions are not supported in ESLint v9. **StandardJS** does provide [eslint-config-standard](https://github.com/standard/eslint-config-standard), but along with the core project, it does not appear to be actively maintained, is still using the deprecated **ESLint** style rules and has an error so cannot be used.

> See [Switch to new eslint config format](#991) for more details on why this was blocking us

We'd resigned ourselves to manually copying and updating the rules from their plugin when we revisited an old issue when first switching to **ESLint** with **StandardJS**. [Support for Eslint v9 Flat Config format](standard/eslint-config-standard#411) was one of the blockers that meant to have both **ESLint** and **StandardJS** play ball, we were stuck on ESLint v8.

We spotted that there had been some [recent activity](standard/eslint-config-standard#411 (comment)), all of which referenced an alternative called [neostandard](https://github.com/neostandard/neostandard).

And oh gosh! All our dreams were answered.

- Built for ESlint to avoid the need for separate IDE tooling
- Built for the latest ESLint (v9), so flat-file config is supported
- Just like we did, any style rules have been updated to use @stylistic/eslint-plugin
- An explicit desire to work with current practices. So, built for use with ESLint only, banning or requiring `;` is now an option, and disabling style rules for those opting to use **prettier** is possible

For context, maintenance on **StandardJS** and related packages like **eslint-config-standard** has been stalled for some time. **neostandard** references the issue as being a [block in governance and direction of travel](standard/standard#1948 (comment)). I've not been through every message, but it appears the maintainers are split between those who remained committed to StandardJS's 'one-tool one-way' approach and those looking to move to where most folks are: **ESLint**.

Even our own @johnwatson484 [has gotten involved!](standard/standard#1948 (comment)).

We're betting this isn't going to be resolved any time soon, so to avoid us having to maintain standard rules in our ESLint config manually, the final fundamental change to highlight is we're now using ESLint + neostandard to manage coding rules.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

8 participants