eslint-types / eslint-define-config Goto Github PK
View Code? Open in Web Editor NEWProvide a defineConfig function for .eslintrc.js files
License: MIT License
Provide a defineConfig function for .eslintrc.js files
License: MIT License
Vue has something like this: https://vuejs.org/guide/typescript/options-api.html#augmenting-global-properties
@antfu suggested to try out to support this, so plugin authors can define their own TypeScript definitions and eslint-define-config
would then just use these.
So code in the specific plugin projects would look like this:
import type { DeprecationRuleConfig } from './rules/deprecation/deprecation';
declare module 'eslint-define-config' {
interface Rules {
/**
* Do not use deprecated APIs.
*
* @see [deprecation](https://github.com/gund/eslint-plugin-deprecation)
*/
'deprecation/deprecation'?: DeprecationRuleConfig;
}
}
import type { AdjacentOverloadSignaturesRuleConfig } from './rules/typescript-eslint/adjacent-overload-signatures';
// ...
declare module 'eslint-define-config' {
interface Rules {
/**
* Require that function overload signatures be consecutive.
*
* @see [adjacent-overload-signatures](https://typescript-eslint.io/rules/adjacent-overload-signatures)
*/
'@typescript-eslint/adjacent-overload-signatures'?: AdjacentOverloadSignaturesRuleConfig;
// ...
}
}
Flat configs should be deep frozen so they can't be mutated. For example:
https://github.com/eslint/eslint/blob/4391b71e62b15e54b0493f0dce1ea053ebbc0689/packages/js/src/configs/eslint-recommended.js#L12
Because the config is now flat and config extending happens in user-land, users may try to extend a config by mutating the actual object. Allowing mutation will cause unexpected behavior in complex configurations where multiple config/plugins depend on a shared config.
I think defineFlatConfig
is a good place to freeze the config.
It looks like engines.pnpm
recently jumped from 7.0.0
to 8.6.0
. Is this strictly necessary for the package to function? Now, when I try to pnpm install
, I get the following error:
ERR_PNPM_UNSUPPORTED_ENGINE Unsupported environment (bad pnpm and/or Node.js version)
Your pnpm version is incompatible with "/eslint-define-config/1.21.0".
Expected version: >= 8.6.0
Got: 8.5.1
This is happening because the package's manifest has an engines.pnpm field specified.
To fix this issue, install the required pnpm version globally.
To install the latest version of pnpm, run "pnpm i -g pnpm".
To check your pnpm version, run "pnpm -v".
I didn't know pnpm concerned itself with engines.pnpm
of upstream deps until now. Given that it does, is it possible to rollback the config?
So the issue is this:
config.plugins is typed using ESLint.Plugin
which contains a rules field which is typed: Record<string, ((...args: any[]) => any) | Rule.RuleModule> | undefined;
However, there are a lot of assignability issues between the way the definitely typed eslint package types rules and the way rules are typed here.
Is there a way we can fix this so that they are properly assignable?
Hope that issue was clear, thanks!
Hi,
I was trying to use @eslint-types/typescript-eslint
with flat config but I found that the plugin field does not support type augmentation
In FlatESLintConfig
, it is:
plugins?: Record<string, ESLint.Plugin>;
Contrary to the legacy config in which it extends from LiteralUnion<keyof CustomPlugins>
Could you add support for plugin augmentation in flat config to make typescript-eslint plugin type work?
Thanks
FlatESLintConfig’s LanguageOptions["parser"]
should accept an object containing parse
, but it is currently using the Parser
type from the old config format which is string only.
I see over 25 rules with
[k: string]: any;
which disappear if json-schema-to-typescript
is configured with { additionalProperties: /* default to: */ false }
I think at least 75% of that is schema typos, and we should use { additionalProperties: /* default to: */ false }
If the type actually has additionalProperties it is always written in type (as Record
types obviously require them to exist), while when it hasn't it may be just be forgotten
https://github.com/mdx-js/eslint-mdx
I'd like to raise a PR if it's accepted.
After #204 was merged and released in 1.21.0, I can't do any type imports, i.e:
import type { FlatESLintConfigItem } from 'eslint-define-config';
Works correctly for 1.20.0
project: null
project
at typescript-eslint > ParserOptions.project and the Docs - ParserOptions.project, I see:project?: string | string[] | true;
true
value has been added in version v5.52.0 via this PR:
null
value, but we are definitely missing the true
valueWhen using:
export default ['eslint:recommended']
... I receive:
The 'eslint:recommended' string configuration is deprecated and will be replaced by the @eslint/js package's 'recommended' config.
Shall the following type be removed?
https://github.com/Shinigami92/eslint-define-config/blob/2eac0b22b1c7f22487a32dc7ccf6476a73fb7765/src/flat-config/index.d.ts#L73
So I'm currently rewriting my eslint config using your awesome plugin. And here are the plugins that are not supported for the moment:
Are you ok to add them?
Should we just generate them automatically? I don't think I've seen a place where there are manually redigested types, but if the need arises, I'm okay with taking care of it.
I was using https://eslint.org/docs/latest/use/configure/migration-guide#using-eslintrc-configs-in-flat-config to try to convert from the old config to flat config.
import { defineFlatConfig } from "eslint-define-config";
import { FlatCompat } from "@eslint/eslintrc";
const compat = new FlatCompat({
baseDirectory: __dirname
});
// js.configs.recommended is basically "eslint:recommended"
import js from "@eslint/js";
import eslintConfigPrettier from "eslint-config-prettier";
export default defineFlatConfig([
js.configs.recommended,
eslintConfigPrettier,
...compat.extends("eslint-config-turbo"),
{
plugins: {
// plugins...
},
rules: {
// rules...
}
}
]);
But ...compat.extends("eslint-config-turbo") error out even though it should work
If I use jsdoc with the types from "eslint"
// js.configs.recommended is basically "eslint:recommended"
import js from "@eslint/js";
import eslintConfigPrettier from "eslint-config-prettier";
import { FlatCompat } from "@eslint/eslintrc";
const compat = new FlatCompat({
baseDirectory: __dirname
});
/**
* @type {import("eslint").Linter.FlatConfig[]}
*/
export default [
js.configs.recommended,
eslintConfigPrettier,
...compat.extends("eslint-config-my-config"),
{
plugins: {
// plugins...
},
rules: {
// rules...
}
}
];
It starts to work but it would be great if this plugin worked with the convertion.
It is unclear when I would use defineFlatConfig()
over /** @type {import("eslint").Linter.FlatConfig} */
On version 1.24.0
, only the file index.cjs
is present in the dist
folder (see the package content on npm).
The files index.js
and index.d.ts
that are referenced in the package.json
are not present.
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates are currently rate-limited. Click on a checkbox below to force their creation now.
These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
@types/eslint
, @types/node
, npm-run-all2
, rimraf
, tsup
, tsx
)@eslint-types/typescript-eslint
, @typescript-eslint/eslint-plugin
, @typescript-eslint/parser
)@vitest/coverage-v8
, vitest
).github/workflows/ci.yml
actions/checkout v4@b4ffde65f46336ab88eb53be808477a3936bae11
actions/setup-node v4@60edb5dd545a775178f52524783378180af0d1f8
actions/checkout v4@b4ffde65f46336ab88eb53be808477a3936bae11
actions/setup-node v4@60edb5dd545a775178f52524783378180af0d1f8
actions/checkout v4@b4ffde65f46336ab88eb53be808477a3936bae11
actions/setup-node v4@60edb5dd545a775178f52524783378180af0d1f8
.github/workflows/publish.yml
actions/checkout v4@b4ffde65f46336ab88eb53be808477a3936bae11
actions/setup-node v4@60edb5dd545a775178f52524783378180af0d1f8
package.json
@eslint-types/prettier ~5.1.3
@eslint-types/typescript-eslint ~7.2.0
@types/eslint ~8.56.7
@types/json-schema ~7.0.15
@types/node 20.12.4
@typescript-eslint/eslint-plugin ~7.5.0
@typescript-eslint/parser ~7.5.0
@vitest/coverage-v8 ~1.4.0
change-case ~5.4.4
eslint ~8.57.0
eslint-config-prettier ~9.1.0
eslint-gitignore ~0.1.0
eslint-plugin-prettier ~5.1.3
expect-type ~0.19.0
json-schema ~0.4.0
json-schema-to-typescript ~13.1.2
npm-run-all2 ~6.1.2
prettier 3.2.5
prettier-plugin-organize-imports ~3.2.4
rimraf ~5.0.5
tsup ~8.0.2
tsx ~4.7.2
typescript ~5.4.4
vitest ~1.4.0
node >=18.0.0
npm >=9.0.0
pnpm >=8.6.0
pnpm 8.15.6
eslint-define-config type hinting does not work when volar take over mode is enabled
Currently the generator only shows generated in green and errors in red.
I would love to see updated count 🙂
Optionally we could also show deleted file count and e.g. deprecations 🤔
Hi, I found awesome this package yesterday and I am currently using this package now.
When I was setup eslint configs with this, I found guide on docs:
// @ts-check
const { defineConfig } = require('eslint-define-config');
/// <reference types="@eslint-types/typescript-eslint" />
module.exports = defineConfig({
root: true,
rules: {
// rules...
},
});
When I remove triple slash reference I can infer @eslint-types/typescript-eslint types. So my question is that should i write triple slash reference on config file? Maybe this question is based on typescript.
Thank you.
This version (commit e23b186#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519L121) drops node 16 support and breaks our project, as we depends on @vue/eslint-config-airbnb-with-typescript that depends on eslint-define-config@^1.6.0.
We still need node 16 because of issue with webpack (webpack/webpack#14532) :(
This breaking change seems unintentional and released with a patch version, is it necessary to drop node 16 support? Could we add back node 16 to the engines field and/or move the incompatible changes to a major version?
Hey !
I just discovered the project, and it's really great to make custom eslint configurations. Really, an incredible job, well done 👏
I realized that you added support for eslint-plugin-node
. which is cool, but this plugin has not been maintained for a while. People are starting to migrate to eslint-plugin-n
which is a fork. And it's possible that a repo transfer will be done soon :
mysticatea/eslint-plugin-node#341
I don't know exactly all the changes between the two repositories, all I know is that many things are in common.
So we have two choices, either totally drops the first one for the second plugin, or support both. I would be more in favor of dropping eslint-plugin-node
.
I can't promise anything because I'm a little short on time right now, but I'm willing to propose a PR after I get your opinion.
Thanks again for this fabulous project which is a life saver!
Check out the list of known eslint schema bugs at eslint/eslint#16879
array-element-newline
nonblock-statement-body-position
no-sequences
no-constructor-return
As we know that they are actual mistakes that won't be fixed anytime soon, it worth fixing them on our side
Good call on moving typing of plugins in a separate @types alias + support from plugin themself via module declaration, install size was one of the main reason I didn't add the lib to the React templates.
I've looked at the v2 output and I see that src is shipped and doesn't bing more than dist it seems. Also not sure about the tsconfig there, it sometimes make tsc behaves strangely.
Wow, found this is so cool, can we add support for eslint-plugin-unicorn?
https://ota-meshi.github.io/eslint-plugin-yml
Is it something you will be willing to work on or accept pr? I haven't really looked at this project code to open pr right this moment but I could try.
The generated file for eslint/max-len
can be optimized.
The rule has 3 times the same pattern.
Instead of generating a config
and option
type, we can reuse the setting
type.
in the .eslintrc.js
file the intellisense there is not
maybe because filename starts with dot
I'm not sure if the problem is related to this package but maybe i'm not the only one with this problem
any suggestions?
node Version too high
https://arethetypeswrong.github.io/?p=eslint-define-config%401.23.0
It is impossible to import types correctly into a node.js project using
"module": "node16",
"moduleResolution": "node16",
v1.20 is the last version that worked correctly
I think it would be cool to do a good refactoring of the type generation script ( scripts/generate-rule-file.ts
).
Currently, for a newcomer to the codebase ( like me 😋 ), it's quite complicated to understand/maintain or extend. And this is the core of eslint-define-config.
If you're interested I can try to propose a PR with something cleaner ( from my POV ), when I have some time to do it. And by the way, adding some tests would be awesome.
Since you are very active in the Vite ecosystem, I imagine that you would be more in favor of using Vitest.
However, I would still like to suggest to use Japa, a test runner that I help to maintain and make evolve. It is a test runner that is focused on testing NodeJS libs/applications, and that does not perform any code transformation.
However, if you prefer Vitest, no worries, it is also a tool that I absolutely love. 💖
Feel free to close the issue if you are not interested, no worries !
If instead of
export type PreferGlobalProcessOption = 'always' | 'never';
export type PreferGlobalProcessOptions = [PreferGlobalProcessOption?];
export type PreferGlobalProcessRuleConfig = RuleConfig<PreferGlobalProcessOptions>;
export interface PreferGlobalProcessRule {
'n/prefer-global/process': PreferGlobalProcessRuleConfig;
}
the typings would use
export interface PreferGlobalProcessRule {
'n/prefer-global/process': RuleConfig<[('always' | 'never')?]>;
}
the intellisence would hint the type as
(property) PreferGlobalProcessRule['n/prefer-global/process']: RuleConfig<[("always" | "never")?]>
(property) NoSyncRule['n/no-sync']: RuleConfig<{
allowAtRootLevel?: boolean;
}>
which may be more understandable for simple types
The same thing also could be done on the type level of defineConfig
itself
I'm trying to use this in my FlatConfig, but without success. Looking at the latest PRs, this should be supported, but in the docs there is no such mention, even less so an explanation for complex usage.
For reference, this is where i'm trying to use it: https://github.com/AndreaPontrandolfo/sheriff/blob/master/configs/eslint.config.js
Expand the docs on how to use this with the FlatConfig, also for complex usage.
By moving the config types to https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/eslint (or one of its related repos) plugins/extensions that use typescript are able to augment the config without adding a third-party dependency.
(This only applies to the config type
s, not the defineConfig
function that uses them)
When dual-publishing libraries, CJS and MJS bundles must have different .d.ts files. Currently there is only type declaration file, which is for the MJS bundle.
Checked with:
PR is coming with the fix:)
Trying to make ESLint lint AND ts-check itself, I encountered the error
Parsing error: ESLint was configured to run on
<tsconfigRootDir>/.eslintrc.cjs
usingparserOptions.project
: /tsconfig.json
However, that TSConfig does not include this file. Either:
- Change ESLint's list of included files to not include this file
- Change that TSConfig to include this file
- Create a new TSConfig that includes this file and include it in your parserOptions.project
See the typescript-eslint docs for more info: https://typescript-eslint.io/linting/troubleshooting#i-get-errors-telling-me-eslint-was-configured-to-run--however-that-tsconfig-does-not--none-of-those-tsconfigs-include-this-fileeslintAlternatively, you can add
parserOptions: { project: null }
to an override for the files you wish to exclude. Note that{ project: undefined }
will not work.
Which could be fixed with
overrides: [{
"files": [".eslintrc.cjs"],
parserOptions: { project: null /* <- add nul*/ },
}],
Which requires parserOptions.project to be nullable as per above link
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.