eslint-stylistic/eslint-stylistic

Monorepo for ESLint Stylistic plugins and configs

ESLint Stylistic

Documentation | Discord | Why | Migration | Project Progress

Community-maintained stylistic/formatting ESLint rules for JavaScript and TypeScript.

This project was initiated as ESLint and typescript-eslint teams decided to deprecate formatting/stylistic-related rules from their core due to the maintenance cost. This repo ports those rules and distributes them as separate packages and will keep them maintained by the community.

License

MIT License

© OpenJS Foundation and other contributors, <www.openjsf.org>
© 2023-PRESENT ESLint Stylistic contributors

eslint-stylistic's Issues

`ts/padding-line-between-statements` removing blank line between functions in interface not working

Reference issue and details are below:
typescript-eslint/typescript-eslint#7909

brace-style recommended options different to default options in docs

Additional context

Description

In documentation, brace-style default options are 1tbs and "allowSingleLine": false but in recommended config factory is stroustrup and "allowSingleLine": true. This leads to some confusing.

Code location

https://github.com/eslint-stylistic/eslint-stylistic/blob/cb1db1ba50732155f1b7a7f83342a9105fc138d8/packages/eslint-plugin/configs/customize.ts#L64

Auto-fix for `style/max-len`

It would be a great enhancement being able to auto-fix style/max-len linting errors without having to use Prettier.

Rename func-call-spacing to function-call-spacing

Overview

Moving from Discord, I propose renaming of rule func-call-spacing to function-call-spacing for the following reasons:

1. Inconsistent naming scheme based on the following function-related rule name:
   a. function-call-argument-newline
   b. function-paren-newline
2. Clearer and more concise rule name. This rule is referring to functions and not to be confused with similar-sounding terms like functor

arrow-parens linting error

/js/arrow-parens rule causes lint to error on an arrow function assignment, e.g. const x = (a) => 1;

"rules": {
    "@stylistic/js/arrow-parens": ["warn", "as-needed"]
}

JS examples of failure

const x = (a) => 1;
const xx = a => 1;

Error message

Oops! Something went wrong! :(

ESLint: 8.19.0

TypeError: Cannot read properties of undefined (reading 'getTokenBefore')
Occurred while linting /project/test.js:1
Rule: "@stylistic/js/arrow-parens"
    at findOpeningParenOfParams (/project/node_modules/@stylistic/eslint-plugin-js/dist/arrow-parens.js:84:44)
    at ArrowFunctionExpression[params.length=1] (/project/node_modules/@stylistic/eslint-plugin-js/dist/arrow-parens.js:135:30)
    at ruleErrorHandler (/project/node_modules/eslint/lib/linter/linter.js:1114:28)
    at /project/node_modules/eslint/lib/linter/safe-emitter.js:45:58
    at Array.forEach (<anonymous>)
    at Object.emit (/project/node_modules/eslint/lib/linter/safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (/project/node_modules/eslint/lib/linter/node-event-generator.js:297:26)
    at NodeEventGenerator.applySelectors (/project/node_modules/eslint/lib/linter/node-event-generator.js:326:22)
    at NodeEventGenerator.enterNode (/project/node_modules/eslint/lib/linter/node-event-generator.js:340:14)
    at CodePathAnalyzer.enterNode (/project/node_modules/eslint/lib/linter/code-path-analysis/code-path-analyzer.js:795:23)

Inclusion of barely-more-than-formatting rules?

Following up on eslint/eslint#17522 & #19: I think there is a small discrepancy between the name (stylistic) of this plugin and what it's going to be used by most devs as at time of announcement (formatting). eslint/eslint#17522 mentions several rules that aren't covered by some or all formatters, but debatably may fall into the category of stylistic rules this plugin should cover:

• curly
• padding-line-between-statements
• no-unexpected-multiline
• no-mixed-operators

Would it be reasonable to include these rules in eslint-stylistic, but only enable them in a dedicated config for non-formatting stylistic rules? If not, and this config really is just for the formatting rules, maybe it should be named eslint-formatting after all? (is that a false dichotomy?)

For anecdotal context/evidence, in https://github.com/JoshuaKGoldberg/create-typescript-app (which uses Prettier for formatting):

• curly is provided by https://github.com/JoshuaKGoldberg/prettier-plugin-curly (https://github.com/JoshuaKGoldberg/create-typescript-app/blob/ae148f607cdd79e829d8c7dfcec28045a3eb3953/.prettierrc#L7)
• @typescript-eslint/padding-line-between-statements is being run in ESLint (https://github.com/JoshuaKGoldberg/create-typescript-app/blob/ae148f607cdd79e829d8c7dfcec28045a3eb3953/.eslintrc.cjs#L163)

cc @bradzacher

@stylistic/indent doesn't work correctly

Hi, tried migrating to @eslint-stylistic, replaced just one rule, and got over a hundred errors. For example, in places like this:

"@stylistic/eslint-plugin": "1.0.0",
"eslint": "8.53.0",

"plugins": ["@stylistic"],
"rules": {
  "@stylistic/indent": ["error", 2],
}

Maximum call stack exceeded when using colon in property names e.g onSetup:context

when using "@stylistic/indent": ["error", 2] the rule crashes when having colons in the property names with is common for vue3 e.g onUpdate:state={}

docs: enhance rules documentation

Clear and concise description of the problem

Currently, the documentation page does not show:

1. fixable
2. hasSuggestion

although both ESLint documentation and TypeScript ESLint documentation shows this. It would be nice if the documentation site shows this so users don't have to navigate back and forth to ESLint or TypeScript ESLint to check whether a deprecated rule is fixable or not.

This issue stems from this discussion

Suggested solution

Add 2 new columns that signifies fixable and hasSuggestions

Alternative

No response

Additional context

I can work on this

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

"comma-dangle" rule broken with enums

Describe the bug

I use the rule :

      '@stylistic/comma-dangle': ['error', {
          'arrays': 'always-multiline',
          'objects': 'always-multiline',
          'imports': 'never',
          'exports': 'never',
          'functions': 'never'
      }]

it can't work for ts's enum.

I expected :

enum foo {
  aaa,
  bbb,
  ccc,
}

But it's like this (the last , has been removed)

enum foo {
  aaa,
  bbb,
  ccc
}

the eslint-config-airbnb has solved this issue , but stylistic not.
iamturns/eslint-config-airbnb-typescript#147

Reproduction

https://stackblitz.com/edit/eslint-stylistic-eslint-stylistic-sqj981?file=playground%2Feslint.config.js,playground%2Findex.ts

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
• The provided reproduction is a minimal reproducible of the bug.

Bug: [lines-around-comment] afterHashbangComment option is not supported on TS

Cross-posting issue from typescript-eslint/typescript-eslint#6636

---

Playground Link

https://typescript-eslint.io/play/#ts=5.0.1-rc&sourceType=module&code=MQQgZg9hBQBuCGAnABAE3gT2QXmQIgHNEBTeAFz2iA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6RplWgQ2gHtYTACa0yfALbjELdGADa4bDkTR+0SABpFSrEuyRuAM3wqAEt2QALAEbcmAcwDCEqTIz44ibdgC+3gLqKfj5AA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA

Repro Code

#!foo
var day = "great"

ESLint Config

module.exports = {
  parser: "@typescript-eslint/parser",
  rules: {
    "@typescript-eslint/lines-around-comment": [
      "error",
      {
        "afterHashbangComment": true
      }
    ]
  },
};
tsconfig
{
  "compilerOptions": {
    // ...
  }
}

Expected Result

Should not crash, should warn about missing blank line after hashbang comment

Actual Result

Configuration for rule "@typescript-eslint/lines-around-comment" is invalid:
Value {"afterHashbangComment":true,"beforeBlockComment":true,"afterBlockComment":false,"beforeLineComment":false,"afterLineComment":false,"allowBlockStart":false,"allowBlockEnd":false} should NOT have additional properties.

Additional Info

The playground example doesn't crash, but CLI crashes.

Consider to add object-property-newline with enhanced object literals?

Related discussions:
eslint/eslint#6211
eslint/eslint#6251

We would like to accomplish the following use cases by combining object-property-newline and object-curly-newline
Good

Object.assign(stream, {
  isTTY: true, columns: false,
});

Bad

Object.assign(stream, {
  isTTY: true, 
  columns: false,
});

Good

Object.assign(stream, {
  isTTY: true,
  columns: false,
  rows: false,
  foo: false,
  bar: false,
  meme: false,
});

Bad

Object.assign(stream, { isTTY: true, columns: false, rows: false, foo: false, bar: false, meme: false, });

Rule @stylistic/comma-dangle looks for languageOptions which doesn't exist/undefined

Not sure whats going on but migrate works and the plain plugin does not.

parserOptions with ecmaVersion is set so not sure again how that ends up as languageOptions

eslint 8.53

VSCode ESLint extension throws TypeError on indent

Problem

Using eslint-stylistic (v1.0.0) is throwing an error on my migrated indent rule while using VScode's ESLint extension (v2.4.2).

Note: running eslint directly in terminal (eslint .) has no such error, and correctly shows linting issues.

Removing the rule entirely then generates a similar looking (but not the same) failure on a different rule... my best guess is that 'sourceCode' isn't being passed correctly? Is this something you can help look at or should I discuss with the ESLint Extension owner?

Thanks!

Rule

    "@stylistic/indent": [
        "error",
        "tab",
        { "SwitchCase": 1 } 
    ],

Error

[Error - 22:56:18] An unexpected error occurred:
[Error - 22:56:18] TypeError: Error while loading rule '@stylistic/indent': Cannot read properties of undefined (reading 'tokensAndComments')
Occurred while linting /Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/homekit/AirConditioner.js
    at new TokenInfo (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/@stylistic/eslint-plugin-js/dist/indent.js:189:31)
    at Object.create (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/@stylistic/eslint-plugin-js/dist/indent.js:688:23)
    at create (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/@stylistic/eslint-plugin-ts/dist/indent.js:108:28)
    at Object.create (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/@typescript-eslint/utils/dist/eslint-utils/RuleCreator.js:38:20)
    at createRuleListeners (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/eslint/lib/linter/linter.js:926:21)
    at /Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/eslint/lib/linter/linter.js:1108:110
    at Array.forEach (<anonymous>)
    at runRules (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/eslint/lib/linter/linter.js:1045:34)
    at Linter._verifyWithoutProcessors (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/eslint/lib/linter/linter.js:1397:31)
    at Linter._verifyWithConfigArray (/Users/malcolm/dev/projects/homebridge-sensibo-ac-nitaybz/node_modules/eslint/lib/linter/linter.js:1772:21)

Config Presets

Could you add a "all" (like "eslint:all") and "recommended" (like "eslint:recommended") rule configurations?

My philosophy is that I turn on all rules, then disable the ones that are not for my project. That way I don't have to keep track of new rules being added or changed.

Refactor to ESM

We could now shart refactoring js and jsx rules to ESM, for better consistency and long-term maintainability. The bundling and testing tools should already support CJS/ESM interchangeability, so we should be able to refactor them progressively. After all modules are migrated to ESM, then we could start migrating to TS later.

If you want to help, leave a comment below describing what you want to work on to avoid duplicate of work. Small PRs (targeting the refactor/esm branch) that migrate part by part would be appreciated instead of a single giant PR. Thanks!

`all` configs preset

Clear and concise description of the problem

Ref: #163

Suggested solution

Introduce all-flat and all-legacy configs that simply enable all rules with their default configs.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Docs style is confusing

Reproduction
When accessing any path that does not exist under the document path, the 404 page will be matched to the home page, and style confusion will occur when entering other pages.

Environments

macOS 14 , Microsoft Edge latest version and Chrome latest version

I only saw the rules for js and ts. Will vue2 rules be added later?

`ts/indent` Problems with the indent rule

Mirror of typescript-eslint/typescript-eslint#1824

TL;DR - the indent rule is broken on TypeScript codebases. Due to bandwidth constraints it will remain broken indefinitely unless the community is able to step up to fix it. Many users are working around it via ESLint disable comments, and configuring certain nodes as ignored; both of which are poor experiences.

[padding-line-between-statements] Documented `cjs-import` and `cjs-export` statement types are not accepted

The documentation of the padding-line-between-statements rule states that cjs-import and cjs-export are valid statement types.

However, linting the following JS file with the following command results in an error.

const path = require('node:path');
module.exports = {};

gebsh@gebsh % eslint --no-eslintrc --env es2023 --plugin '@stylistic' --rule '@stylistic/padding-line-between-statements: [error, { blankLine: always, prev: cjs-import, next: cjs-export }]' ./test.cjs

Oops! Something went wrong! :(

ESLint: 8.53.0

Error: CLIOptions:
	Configuration for rule "@stylistic/padding-line-between-statements" is invalid:
	Value "cjs-import" should be equal to one of the allowed values.
	Value "cjs-import" should be array.
	Value "cjs-import" should match some schema in anyOf.

I believe this is caused by the fact that @typescript-eslint renames these two options to require and exports: typescript-eslint/typescript-eslint#4091. Renaming them in the configuration does work:

gebsh@gebsh % eslint --no-eslintrc --env es2023 --plugin '@stylistic' --rule '@stylistic/padding-line-between-statements: [error, { blankLine: always, prev: require, next: exports }]' ./test.cjs

<project-root>/test.cjs
  2:1  error  Expected blank line before this statement  @stylistic/padding-line-between-statements

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Contradicting doc (option "always") for semicolon

In the docs for semi, you state that always was the default option.

https://github.com/eslint-stylistic/eslint-stylistic/blob/62a83bb5f07542806edba778bbfe334a18bbd4c8/packages/eslint-plugin-js/rules/semi/README.md?plain=1#L78

However, when I use the following configuration in .eslintrc.js:

const stylistic = require("@stylistic/eslint-plugin");

const customized = stylistic.configs.customize({
  indent: 2,
  quotes: "double",
});

module.exports = {
  root: true,
  parserOptions: {
    ecmaVersion: 2024,
    sourceType: "module",
  },
  env: {
    browser: true,
    jquery: true,
  },
  extends: "eslint:recommended",
  plugins: [
    "@stylistic",
  ],
  rules: {
    ...customized.rules,
    "no-unused-vars": "warn",
  },
};

I get errors for having semicolons ("Extra semicolon"), such that I manually have to set

const customized = stylistic.configs.customize({
  indent: 2,
  quotes: "double",
  semi: "always",
});

I don't know but maybe this is related to this line?

https://github.com/eslint-stylistic/eslint-stylistic/blob/62a83bb5f07542806edba778bbfe334a18bbd4c8/packages/eslint-plugin-js/configs/disable-legacy.ts#L59

Porting JSX stylistic rules from `eslint-plugin-react`

https://github.com/jsx-eslint/eslint-plugin-react

A few considerations:

• eslint-plugin-react is React specific, while many of the stylistic rules are actually general to JSX syntaxes
• Port stylistic rules would allow other JSX frameworks (solid, qwik, vue jsx, etc.) to reuse them without re-implement, or introducing eslint-plugin-react for that.

Missing rule: typescript-eslint/type-annotation-spacing

https://typescript-eslint.io/rules/type-annotation-spacing

I finally went over the list in eslint/eslint#17522 and didn't see it anywhere (eslint/eslint#17522 (comment)). Is it doable to add this in too? cc @bradzacher

Unavailable rules documentation leads to 404

Overview

It seems like rules that are yet be available in eslint-stylistic can be accessed on the documentation page that leads to 404. This is confusing as the rules aren't actually available on the code yet. I suggest we redirect it to a WIP page or delete it from the navigation.

Example rules: newline-after-var, newline-before-return

New rule: `function-argument-newline`

Clear and concise description of the problem

I like for styling to always have one line per elements/argument/properties. That's why I added for the arrays these two rules array-element-newline array-bracket-newline. Now for functions I want to have the same behavior, therefore I activated these rules function-call-argument-newline function-paren-newline. But even in this situation I can still have function declaration that look like that:

function foo(
	a, b,
) {
	bar(
		a,
		b,
	)
}

Suggested solution

I have the feeling that a rule called function-argument-newline is missing here. The enforced result would be something like that:

function foo(
	a, 
	b,
) {
	bar(
		a,
		b,
	)
}

Alternative

No response

Additional context

Currently both solution are valid for the linter. I just want to avoid having the choice :)

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

sourceCode undefined in every rule

I created package with own rules where I use stylistic with next/recommended

// eslin-plugin-test/index.js

module.exports = {
  configs: {
    nextjs: {
      plugins: ["@stylistic"],
      extends: ["plugin:@next/next/recommended"],
      rules: {
        "@stylistic/max-len": ["error", 120],
      },
    },
  },
};

Then I use it in my NextJS project

//  nextproject/.eslintrc.js

/** @type {import('eslint').Linter.Config} */
module.exports = {
  root: true,
  extends: ['plugin:@test/test/nextjs'],
  parserOptions: {
    project: './tsconfig.json',
    ecmaVersion: 'latest',
  },
  env: {
    es6: true,
    node: true,
  },
};

The problem is that every rule added into rules in index.js file causes an error:

[Error - 18:41:35] TypeError: Cannot read properties of undefined (reading 'lines')
Occurred while linting /Users/silon/Developer/nextjs-template/.eslintrc.js:2
Rule: "@stylistic/max-len"
    at checkProgramForMaxLength

The problem in this case is in max-len.js file in this line:

function checkProgramForMaxLength(node) {
  // split (honors line-ending)
  const lines = sourceCode.lines;

When I remove max-len rule from index.js eslint works good

Could not find a declaration file for module '@stylistic/eslint-plugin'

Describe the bug

Hovering over import stylistic from '@stylistic/eslint-plugin' shows message captured in attached image.

Could not find a declaration file for module '@stylistic/eslint-plugin'. '/.../stylistic-eslint-plugin-declaration/node_modules/.pnpm/@Stylistic[email protected][email protected][email protected]/node_modules/@stylistic/eslint-plugin/dist/index.js' implicitly has an 'any' type.
Try npm i --save-dev @types/stylistic__eslint-plugin if it exists or add a new declaration (.d.ts) file containing declare module '@stylistic/eslint-plugin';

Reproduction

https://github.com/erichosick/stylistic-eslint-plugin-declaration

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
• The provided reproduction is a minimal reproducible of the bug.

Migrate to TypeScript

#66 has done the initial work and tooling setup to bundle and type checking.

We still have many rules rewritten in JavaScript. Help would be much appreciated!

If you want to help, please feel free to leave a comment below to say what rule you want to migrate, and send PRs to the main branch, one PR for a rule.

Migration examples:

• Rules of eslint-plugin-js: a88038e#diff-1c7f529705777d91ed7afa4e5549f6aebc607177bf49bd9f7c19d6c614defd4d
• Rules of eslint-plugin-jsx: a88038e#diff-f2ed5fbe59b664a37dd073cd140a7dd6812bc40757dd51f84a6fc3407becd0a7

False positive for keyword-spacing rule

Class methods:

Version 1.3.1, version 1.2.0 did not have this problem.

auto-fixable

Will some of these rules be auto-fixable?

Additional package for new rules

To make my personal day-to-day ESLint experience better, I created my personal plugin https://github.com/antfu/eslint-plugin-antfu to handle some edge cases.

Some formatting rules are quite straightforward but never presented in the ESLint/typescript-eslint rules. For example:

• generic-spacing
• named-tuple-spacing
• indent-binary-ops - (It's quite useful!)

I assume it might be because both projects have frozen the stylistic rules since 2020. Now with ESLint Stylistic, the door finally open up a bit.

I want to keep the current js ts jsx packages as-is to keep the "1:1" migration mapping in v1.0. So I imagine we could have a separate package like @stylistic/eslint-plugin-extra to host new rules. Later we plan to merge all those 4 packages into a single one, as currently exposed at @stylistic/eslint-plugin.

While I do NOT want to allow any rules to come in and eventually burn out by maintenance burden - so even we are opening the door for new rules, we will be very strict about them. In principle, we'd suggest releasing the proposed rules as separate eslint-plugin to verify them in various codebases first. And later we could start discussing about moving them into this project.

Reduce amount of unneeded third-party polyfills

@stylistic/eslint-plugin-jsx depends on jsx-ast-util which brings a lot of useless polyfill dependencies like object-keys, object.values, array-includes, is-string and many more. In total at least 30-40 packages that no modern JS engine needs.

comma-dangle in TypeScript: Error reported on generics in a .tsx files where the comma is required

Copying the issue from typescript-eslint typescript-eslint/typescript-eslint#7857 as they requested:

Playground Link

https://typescript-eslint.io/play/#ts=5.2.1-rc&fileType=.tsx&code=MYewdgzgLgBAlgExgXhgHgCoBoB8AKADwC4YMBKFHGAgbgFgAoIA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6MgewFsuBDWgCa8mAcyTooiaNA7RI4MAF8QioA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

Repro Code

const id = <T,>(x: T) => x;

ESLint Config

module.exports = {
  parser: "@typescript-eslint/parser",
  rules: {
    "@typescript-eslint/comma-dangle": "error"
  }
};

tsconfig

{
  "compilerOptions": {
    // ...
  }
}

Expected Result

I expected T, wouldn't be considered an error; while the comma is dangling, removing it is an error

2304: Cannot find name 'T'. 1:13 - 1:14
17008: JSX element 'T' has no corresponding closing tag. 1:13 - 1:14

Actual Result

Unexpected trailing comma. 1:12 - 1:16

(and auto-fix results in the TypeScript errors).

Proposal: enhance object-property-newline rule

The potential new options and the use cases have been thoroughly discussed in the past eslint/eslint#6251

Would the community be interested in enhancing this rule?

Enhance `default` package docs with TS-extended options and behavior

Some of the rules that are extended through the TS package have incomplete documentation in the default rule docs. It's currently difficult to go back and forth between the default rule page and the TS rule page (or @typescript-eslint's page) to reference extended options and whether certain behavior is supported - which is a pain point for adoption.

Rules with extended options include (not exhaustive, but covers the ones I'm encountering while setting up a config):

• comma-dangle
• padding-line-between-statements
• lines-around-comment
• lines-between-class-members

It's also not entirely clear whether certain behavior has been extended. One issue I found in the past was when our team tried enforcing "allman" through @typescript-eslint/brace-style - it had an unintended effect of forcing our interfaces to adhere to this style, which forced us to turn off the override (yes, we're aware of other issues with this setting lol).

// This is what we wanted
if (bool)
{
  ...
}

// This was incorrect
interface A {
  ...
}

// But this was ok!
type B = {
  ...
}

So it would be nice to also be alerted ahead of time if a default rule will have behavior beyond what's expected on the docs.

With how our docs our set up in metadata, it would be nice to have your input on how to proceed @antfu

Release 1.0

We are thinking of releasing 1.0 the next week with the current state (1:1 migration from each repo) so that users could be more confidently migrate over, if no major bug/issue occurs before that.

A few future plans in my head:

• v1.0.0
  • 1:1 migration from each source project
• v2.0.0
  • Rewrite in TS with unified tooling
• v3.0.0
  • Merge TS and JS rules into one. Soft deprecate js/ts standalone packages.

Remove jsx-space-before-closing rule

As menthioned in the document, the ”jsx-space-before-closing“ rule is deprecated. It was replaced by react/jsx-tag-spacing. It is recommended to consider removing this rule.

Missed `arrow-parens` docs

It's present in this post https://eslint.org/blog/2023/10/deprecating-formatting-rules/
Present in this plugin https://github.com/eslint-stylistic/eslint-stylistic/tree/main/packages/eslint-plugin-js/rules/arrow-parens

But missed in docs:

[bug] indent + brace-style 'allman': TypeScript enum opening brace is indented

When using:

"rules": {
    "@stylistic/brace-style": ["warn", "allman"],
    "@stylistic/indent": ["warn", indent_size],
}

I expect the following to be correct:

export enum MyEnum
{
    First,
    Second,
}

Instead, the following occurs:

export enum MyEnum 
{
// ^ Expected indentation of 4 spaces but found 0.
    First,
    Second,
}

array multiline allman style

Hello, is there any rule for putting the array bracket to a new line if it is multiline? like Allman style

for example:

First bracket error:

  const array = [
    'props', 
    { hello: 'world' }
  ]

correct method

  const array = 
  [
    'props', 
    { hello: 'world' }
  ]

also these dont work with object

error

const stylisticDisabledRule = {
  'jsx-sort-props': 'off'
};

const array = [
  'error',
  {
    hello: {
      good: "morning"
    }
  }
]

expected correction

const stylisticDisabledRule = 
{
  'jsx-sort-props': 'off'
};

const array = 
[
  'error',
  {
    hello: 
    {
      good: "morning"
    }
  }
]

Edit:

a long time ago in the eslint team, they proposed adding object-curly-style and array-bracket-style as new rules for these cases in this issue #5203, but looks like this never implements

comma-dangle fixes can generate invalid code

Describe the bug

When set to always, comma-dangle complains about a Missing trailing comma in arrow function parameters without parentheses, and even inserts it there as a fix, although no trailing comma is allowed in this case.

For example, a => 42; gets "fixed" to a, => 42; with

{
  "plugins": ["@stylistic/js"],
  "rules": {
    "@stylistic/js/comma-dangle": ["error", "always"]
  }
}

Reproduction

https://stackblitz.com/edit/eslint-stylistic-eslint-stylistic-g3bpwd

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
• The provided reproduction is a minimal reproducible of the bug.

`no-extra-parens` fails with explicit generic type

test.ts:

const fn = <T>(arg: T) => arg;
fn<(null | undefined)[]>([]);

eslint -c eslint.js test.ts:

  2:25  warning  Unnecessary parentheses around expression  @stylistic/no-extra-parens

✖ 1 problem (0 errors, 1 warning)
  0 errors and 1 warning potentially fixable with the `--fix` option.

The autofix will apply this mutation which produces invalid source text:

-fn<(null | undefined)[]>([]);
+fn<(null | undefined)[]>[];

eslint.js:

import stylisticPlugin from "@stylistic/eslint-plugin";
import typeScriptPlugin from "@typescript-eslint/eslint-plugin";
import typeScriptParser from "@typescript-eslint/parser";

/** @type {FlatConfig[]} */
// eslint-disable-next-line import/no-anonymous-default-export
export default [
	{
		files: [ "**/*.ts" ],
		languageOptions: {
			parser: typeScriptParser,
		},
		plugins: {
			"@typescript-eslint": typeScriptPlugin,
			"@stylistic": stylisticPlugin,
		},
		rules: {
			"@stylistic/no-extra-parens": "warn",
		},
	},
];

Docs suggestion: clarify terminology of formatting/style/logic

Surfacing eslint/eslint.org#419 here: in my experience, many users have a hard time differentiating between the concepts of "formatting" and "style". It doesn't help that different ecosystems or tools within the same ecosystem can have subtle differences. I personally had a different vocab from what ESLint core uses until this year!

My understanding of what ESLint core uses -and therefore typescript-eslint too- is what's on https://typescript-eslint.io/linting/troubleshooting/formatting#eslint-core-and-formatting right now:

Most lint rules fall into one of two to three categories:

• Logical: Rules that care about the logic in runtime behavior of code (such as missing awaits or invalid logical checks).
• Stylistic: Rules that care about style concerns which do impact runtime behavior of code, but generally not logic. These are mostly around naming or which roughly-equivalent syntax constructs to use (such as function declarations vs. arrow functions).
  • Formatting: Stylistic rules that care only about trivia (semicolons, whitespace, etc.) without impacting the runtime behavior of the code. These rules conflict with dedicated formatters such as Prettier.

In other words: the two main categories are logical and stylistic, and formatting is a subset of stylistic.

It makes sense to call this repo & org eslint-stylistic- given that the plugin is likely to eventually include some stylistic rules alongside the many formatting ones. But it'd help users understand that if the docs could mention that explicitly. Especially since many users are using eslint-stylistic primarily for formatting concerns.

(this issue came out of a conversation with @antfu, who explained that last paragraph - thanks!)

Aside: eslint.style right now (before full release) has much higher quality docs than most projects do on or after release. Love it. Nicely done! ❤️

Missing rule: typescript-eslint/member-delimiter-style

https://typescript-eslint.io/rules/member-delimiter-style

I finally went over the list in eslint/eslint#17522 and didn't see it anywhere (eslint/eslint#17522 (comment)). Is it doable to add this in too? cc @bradzacher

Project Plans

So the current plan is to port rules from both https://github.com/eslint/eslint and https://github.com/typescript-eslint/typescript-eslint.

They will be released as @eslint-stylistic/eslint-plugin-core and @eslint-stylistic/eslint-plugin-typescript respectively.

I also reserved eslint-config-stylistic for a one-line extend in eslintrc and easy usage. Ideally, the usage would be like:

{
  "extends": ["stylistic"]
}

---

Project Stages

Track on https://eslint-stylistic.netlify.app/contribute/project-progress

---

Current Focus

We shall focus on porting the ESLint core first, here is a few todos:

• Port Rules from ESLint core
  • Migration Scripts
  • Docs
  • Docs Improvements
  • Invite contributors who are interested in maintaining them, or previously contributed to those rules
• Port Rules from typescript-eslint
  • Would be glad to use some help from the typescript-eslint team, if anyone is interested
• Migration tools, to print warning on legacy rules.

Rules seems not working?

https://stackblitz.com/edit/vitejs-vite-iiwk4u?file=README.md

👆 Run pnpm lint:standard and pnpm lint.

no-trailing-spaces is ok while @stylistic/js/no-trailing-spaces not working. Did I miss anything?

Stylistyc rules should disable original rules

I have a problem with overriding rules coming from eslint-config-standard that is using deprecated eslint rules.

For example, standard has defined that quotes should be single quotes. But we prefer double quotes.

This is simplified version of our config that used to work great:
.eslintrc.yml:

extends: standard
rules: 
  quotes: [error, double]

Now, if I want to migrate from the deprecated quotes rule to @stylistic/quotes I'm getting a configuration that is always invalid no matter the state of the code.

.eslintrc.yml:

extends: standard
plugins:
  - "@stylistic"
rules: 
  "@stylistic/quotes": [error, double]

So, if my index.js file looks like this:

console.log("hello world")

Then I'm getting following error

$ yarn eslint --fix index.js 
yarn run v1.22.19
$ /home/hazzik/repos/xxx/node_modules/.bin/eslint --fix index.js

/home/hazzik/repos/xxx/index.js
  1:13  error  Strings must use singlequote  quotes

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

And if I use single quotes:

console.log('hello world')

$ yarn eslint --fix index.js 
yarn run v1.22.19
$ /home/hazzik/repos/xxx/node_modules/.bin/eslint --fix index.js

/home/hazzik/repos/xxx/index.js
  1:13  error  Strings must use doublequote  @stylistic/quotes

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Fix typechecking

Currently the typecheck is disabled in CI as we have stricter rules than typescript-eslint, causing many rules still have type errors. We could migrate them to a stricter type and then enable the general typechecking.

require() of ES Module globby

all of a sudden,
without updating any package,
it happened.

eslint.config.js

import antfu from '@antfu/eslint-config'

export default antfu()

error message:

Error [ERR_REQUIRE_ESM]: require() of ES Module /home/minkoonim/admin/node_modules/globby/index.js from /home/minkoonim/admin/node_modules/@typescript-eslint/typescript-estree/dist/parseSettings/resolveProjectList.js not supported.
Instead change the require of index.js in /home/minkoonim/admin/node_modules/@typescript-eslint/typescript-estree/dist/parseSettings/resolveProjectList.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@typescript-eslint/typescript-estree/dist/parseSettings/resolveProjectList.js:8:18)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@typescript-eslint/typescript-estree/dist/parseSettings/createParseSettings.js:14:30)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@typescript-eslint/typescript-estree/dist/parser.js:17:31)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@typescript-eslint/typescript-estree/dist/index.js:18:16)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@typescript-eslint/type-utils/dist/TypeOrValueSpecifier.js:30:29)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@typescript-eslint/type-utils/dist/isTypeReadonly.js:32:32)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@typescript-eslint/type-utils/dist/index.js:26:14)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@stylistic/eslint-plugin-ts/dist/block-spacing.js:6:1)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@stylistic/eslint-plugin-ts/dist/index.js:3:20)
    at Object.<anonymous> (/home/minkoonim/admin/node_modules/@stylistic/eslint-plugin/dist/index.js:5:10)