Project Plans

[antfu]

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.

[Shinigami92]

In preparation of https://www.npmjs.com/package/@eslint/js I would suggest to not name it core

[antfu]

In preparation of npmjs.com/package/@eslint/js I would suggest to not name it core

Oh interesting, thanks for the heads up! Do you suggest we go with eslint-plugin-(js/ts) or eslint-plugin-(javascript/typescript)?

[xbmlz]

In preparation of npmjs.com/package/@eslint/js I would suggest to not name it core

Oh interesting, thanks for the heads up! Do you suggest we go with eslint-plugin-(js/ts) or eslint-plugin-(javascript/typescript)?

I think it's still js or ts, and this naming is already very common for web developers ^-^

[Shinigami92]

In preparation of npmjs.com/package/@eslint/js I would suggest to not name it core

Oh interesting, thanks for the heads up! Do you suggest we go with eslint-plugin-(js/ts) or eslint-plugin-(javascript/typescript)?

I personally prefer the explicit naming @eslint-stylistic/eslint-plugin-javascript and @eslint-stylistic/eslint-plugin-typescript,
but I will leave the final decision to you

[ota-meshi]

I have a small question. Why separate plugins for js and ts? ts is a superset of js, so I think all ts rules support js.
For example, I think that the indentation rule of @eslint-stylistic/eslint-plugin can also support js if it supports ts.
If a rule requires type information, it might be better to separate the plugin, but I would expect that most stylistic rules do not require type information.

[Shinigami92]

I have a small question. Why separate plugins for js and ts? ts is a superset of js, so I think all ts rules support js. For example, I think that the indentation rule of @eslint-stylistic/eslint-plugin can also support js if it supports ts. If a rule requires type information, it might be better to separate the plugin, but I would expect that most stylistic rules do not require type information.

What about Flow? Or CoffeeScript? Or whatever... 🤔 Aren't they "just" JS with extras? 😅

It would have up- and downsides to have JS/TS mixed in one plugin
The JS code could be traversed much faster then the TS AST, and maybe there are some projects that explicitly only want JS without TS but using JSDocs for expressing the types.

[ota-meshi]

We may need to separate plugins for CoffeeScript and Flow. However, I think ts rules can support js.
If the same rules as ts rules are reimplemented for js, there will be two rule implementations, so I'm concerned that the maintenance cost may increase.
Separating plugins for js may have a small performance advantage, but I think lower maintenance costs should be a priority.

[Shinigami92]

We may need to separate plugins for CoffeeScript and Flow. However, I think ts rules can support js. If the same rules as ts rules are reimplemented for js, there will be two rule implementations, so I'm concerned that the maintenance cost may increase. Separating plugins for js may have a small performance advantage, but I think lower maintenance costs should be a priority.

understandable arguments
let's see what @antfu has to say about that

[antfu]

@ota-meshi A few reasons I can think about:

• We are going to port js rules from ESLint core, and ts rules from typescript-eslint, which means they come from different sources and have different structure/format (e.g. eslint rules are single-file JS, while I image typescript ones they are written in typescript with their own plugin-utils). It's easier we separate them for both communication and maintainability.
• While TS is indeed a superset of JS, I imagine @typescript-eslint/indent would not be 100% identical to indent. If we don't provide the JS version, it might make the migration way harder.
• AFAIK, @typescript-eslint/eslint-plugin requires typescript as a dependency. Which not all projects would have it installed.

To me, the current priority is to make 1:1 port of existing rules and not to think too much about improvements, so the migration can be easier and straightforward. After it get stable and the both ESLint and ts-eslint teams started to redirecting users to us, then we can thinking about how to (refactor/add more rules/improve existing ones/etc).

[Shinigami92]

Yeah, I agree

Additionally: with eslint FlatConfig it will be more and more easy to configure rules for each language individually.

@sxzz might know stuff better specific to FlatConfig
He worked on eslint-define-config for FlatConfig support

[ota-meshi]

@antfu Thank you for your opinion.
I think you're right that separating plugins makes porting and migration easier. Your input made me think that separating the plugins is the best start.

AFAIK, @typescript-eslint/eslint-plugin requires typescript as a dependency. Which not all projects would have it installed.

In my opinion, @typescript-eslint/utils is the only dependency.
The rules require a parser, but I think we can also make it independent of typescript by making @babel/eslint-parser selectable instead of @typescript-eslint/parser.

[kecrily]

I'm interested in this project, and I've had the idea of maintaining separate style rules, but never acted on it because of energy and time issues. What would it take to join in on this?

---

Also don't forget to integrate issues that have been identified in the original rules but not yet fixed, for example, the indent rule has eight open issues,

---

Regarding package naming, I suggest using @eslint-stylistic/* (@eslint-stylistic/js), which is similar to @eslint/js and is not cumbersome with repeated occurrences of eslint. It doesn't quite keep its conventions but I don't think it's a big problem.

[antfu]

Hey @kecrily, glad to hear that. Just send you the invite, welcome :)

---

Also don't forget to integrate issues that have been identified in the original rules but not yet fixed

I wouldn't really bother with it. Instead, I'd think it would be better for the community to bring them up again in this repo, if they are important enough to them. I think we better do it when we finished the migration and infra.

---

Regarding package naming

I actually got the @stylistic org on npm, so awe could have @stylistic/js/indent, which I think it's quite clear now.

You can join https://chat.antfu.me, that we have a channel for this org (later we will see if it needs to be a dedicate server)

[so1ve]

After we started maintaining these rules, shall we convert those rules written in JavaScript into TypeScript? This can reduce some potential errors. I'm glad to contribute to this refactor :)

[antfu]

Yes, definitely