[eslint-plugin] Proposal: Add configuration helper #6090
Replies: 8 comments 2 replies
-
|
@bartlangelaan what do you think about making tool instead of wrapper? we could do 2 things there:
i don't like that this is going to be in plugin, maybe we should make separated package for this? |
Beta Was this translation helpful? Give feedback.
-
|
I think a wrapper is the best option for most people, because if this project gets updated then the wrapper can automatically enable new rules if necessary. Users don't have to think about re-running the tool every time a new replacement rule is added to the plugin. Just updating the plugin would be enough. I understand that it's a new thing and a new package could be good for that, but I think it's more user-friendly if the wrapper comes out of the box with the plugin. That's also because the wrapper is dependent on the right rules being available; it's easy to make the mistake of updating the wrapper without updating the rules, or the other way around. I do think adding a tool that checks these things would be helpful for some, especially for power-users that want to configure every little thing themselves. It's a bit comparable to what eslint-config-prettier has: a little CLI tool that checks for rules that conflict with Prettier. If something like that would be added to this repo that would be awesome; but for 'normal' users I think it would be more friendly to also provide a wrapper. So that's what I would like to focus on in this proposal. |
Beta Was this translation helpful? Give feedback.
-
|
Note that there's eslint/rfcs#9 which might help deal with this. I don't think such a tool belongs directly in the plugin's package, though it could live in this monorepo.
This is an unbounded set. There are a huge number of plugins which provide rules that might already be caught by typescript. I would recommend not providing a blacklist, or else we could possibly playing catchup with users reporting rules that are double reporting with TS's compiler. Would mean we'd have to switch the list that gets disabled based on the plugins installed by the user. Note eslint will throw if you include rules that don't exist; so (depending on the list of rules from plugins) there's the chance that we'd have to detect plugin versions. A bit of bike shedding, but something to think about. Note that there is a lot of parts of this repo that will work on both JS and TS files. Essentially there's one set of rules which will not work on JS files: |
Beta Was this translation helpful? Give feedback.
-
|
It'd be nice if the new package were written in a way that made it seamless to reuse its logic in a standalone CI helper, for teams that use JSON config formats... |
Beta Was this translation helpful? Give feedback.
-
From what I've been told - in future versions of ESLint JSON config files will be deprecated. I believe that they want to standardise on JS config files as they are easier to work with in general, and it simplifies ESLint's config resolution and parsing logic. |
Beta Was this translation helpful? Give feedback.
-
|
Moving this to a discussion because we should hammer out what this configuration helper should look like. What is the API? How are you expected to call it? |
Beta Was this translation helpful? Give feedback.
-
|
The new flat config will likely require us to create a helper package to bundle up the entire project and it's configs in a standardised way. So such a package wpuld us a good place to export such a config utility. Even if the utility starts as an identity function purely for types. |
Beta Was this translation helpful? Give feedback.
-
|
This helper roughly exists in v7. See https://typescript-eslint.io/blog/announcing-typescript-eslint-v7. Cheers all! 💙 |
Beta Was this translation helpful? Give feedback.
-
|
This still doesn't provide a way for automatically configuring ts-eslint replacement rules to use the configuration of the core eslint rules that are being replaced, right? Any thoughts about handling that use case? |
Beta Was this translation helpful? Give feedback.
-
|
Oh! You're right, sorry. Re-opening. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
To get this plugin and the TypeScript parser to work, currently it needs some basic configuration to be added to the ESLint configuration. This amount of configuration grows if it should only apply to TypeScript files, and it even increases more if you extend from a shared configuration (like airbnb's) that implements rules that aren't supported by the TypeScript ESLint parser.
With a configuration helper, we can enable everyone to automatically apply all Typescript-related stuff to your ESLint configuration. It would look something like this:
Then, the
config-helperfunction would apply all transformations needed to get the configuration working. So, the configuration that is actually exported looks like this:{ "extends": ["eslint-config-airbnb", "eslint-config-prettier", "eslint-config-prettier/react"], "plugins": ["prettier"], "env": { "browser": true, }, "rules": { "prettier/prettier": "error", "camelcase": ["error", { "properties:": "never", "ignoreDestructuring": false }], }, "overrides": [ { "files": ["*.ts", "*.tsx"], "parser": "@typescript-eslint/parser", "plugins": ["@typescript-eslint"], "settings": { "import/resolver": { "node": {"extensions": [".js", ".ts", ".jsx", ".tsx", ".json"]}, "typescript": {}}, "import/extensions": [".js", ".ts", ".jsx", ".tsx", ".json"] }, "rules": { "camelcase": 0, "@typescript-eslint/camelcase": ["error", { "properties:": "never", "ignoreDestructuring": false }], "no-array-constructor": 0, "@typescript-eslint/no-array-constructor": ["error"], "import/no-unresolved": 0, "import/named": 0, "react/jsx-filename-extension": 0, "@typescript-eslint/restrict-plus-operands": "error" } } ] }So, what it basically does is:
.tsand.tsxfiles with the right parser and pluginextends) that have a TypeScript-specific rule (likecamelcase&no-array-constructorin this example), and disables the core rule and enables the TS-specific one with the original config.import/no-unresolvedandimport/namedin this example)@typescript-eslint/*rule definitions to the override so they aren't enabled for non-TS files.This way it's way easier to make ESLint compatible with TypeScript, as all needed config changes are handled for you.
Issues related to config, that would probably be helped by this helper: #36 #109 #118 #147 #154 #177 #265 #266 #267 #268
If others agree that this would be helpful, I'm willing to try to make a PR that enables this.
Beta Was this translation helpful? Give feedback.
All reactions