eslint-community / eslint-stylistic Goto Github PK
View Code? Open in Web Editor NEWMonorepo for ESLint Stylistic plugins and configs
Home Page: https://eslint.style
License: MIT License
Monorepo for ESLint Stylistic plugins and configs
Home Page: https://eslint.style
License: MIT License
Copying the issue from typescript-eslint typescript-eslint/typescript-eslint#7857 as they requested:
const id = <T,>(x: T) => x;
module.exports = {
parser: "@typescript-eslint/parser",
rules: {
"@typescript-eslint/comma-dangle": "error"
}
};
{
"compilerOptions": {
// ...
}
}
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
Unexpected trailing comma. 1:12 - 1:16
(and auto-fix results in the TypeScript errors).
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
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
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?
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
await
s 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! โค๏ธ
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
v2.0.0
v3.0.0
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
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",
},
},
];
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):
@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
Cross-posting issue from typescript-eslint/typescript-eslint#6636
#!foo
var day = "great"
module.exports = {
parser: "@typescript-eslint/parser",
rules: {
"@typescript-eslint/lines-around-comment": [
"error",
{
"afterHashbangComment": true
}
]
},
};
tsconfig
{
"compilerOptions": {
// ...
}
}
Should not crash, should warn about missing blank line after hashbang comment
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.
The playground example doesn't crash, but CLI crashes.
#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:
eslint-plugin-js
: a88038e#diff-1c7f529705777d91ed7afa4e5549f6aebc607177bf49bd9f7c19d6c614defd4deslint-plugin-jsx
: a88038e#diff-f2ed5fbe59b664a37dd073cd140a7dd6812bc40757dd51f84a6fc3407becd0a7Reference issue and details are below:
typescript-eslint/typescript-eslint#7909
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?
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:
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)
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,
)
}
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,
)
}
No response
Currently both solution are valid for the linter. I just want to avoid having the choice :)
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.
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.
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.
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.
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!
"@stylistic/indent": [
"error",
"tab",
{ "SwitchCase": 1 }
],
[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)
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
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],
}
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"]
}
}
https://stackblitz.com/edit/eslint-stylistic-eslint-stylistic-g3bpwd
Ref: #163
Introduce all-flat
and all-legacy
configs that simply enable all rules with their default configs.
No response
No response
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.
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.
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.
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';
https://github.com/erichosick/stylistic-eslint-plugin-declaration
Currently, the documentation page does not show:
fixable
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
Add 2 new columns that signifies fixable
and hasSuggestions
No response
I can work on this
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"]
}
Track on https://eslint-stylistic.netlify.app/contribute/project-progress
We shall focus on porting the ESLint core first, here is a few todos:
typescript-eslint
typescript-eslint
team, if anyone is interestedIt 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
Will some of these rules be auto-fixable?
It would be a great enhancement being able to auto-fix style/max-len
linting errors without having to use Prettier.
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
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.
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!
@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.
/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)
In the docs for semi
, you state that always
was the default option.
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/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 syntaxeseslint-plugin-react
for that.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, });
Moving from Discord, I propose renaming of rule func-call-spacing
to function-call-spacing
for the following reasons:
function-call-argument-newline
function-paren-newline
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,
}
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
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):
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.