Configuration Files (New)

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

https://eslint.org/docs/latest/user-guide/configuring/configuration-files-new#configuring-shared-settings

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?

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 types, not the defineConfig function that uses them)

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 🤔

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.

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:

• https://arethetypeswrong.github.io/?p=eslint-define-config%402.1.0
• https://publint.dev/[email protected]

PR is coming with the fix:)

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.

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.

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 !

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.

• Related to this issue #175
  • It's weird that the mentioned troubleshoot doc says we can use project: null
• Looking at the type definitions for project at typescript-eslint > ParserOptions.project and the Docs - ParserOptions.project, I see:

project?: string | string[] | true;

• The true value has been added in version v5.52.0 via this PR:
  • typescript-eslint/typescript-eslint#6084
• Not sure about the null value, but we are definitely missing the true value

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.

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.

https://github.com/vitejs/vite/blob/6a600805f0c2803e843a0af279d5f8cc1a2c4d89/.eslintrc.js#L14

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.

It is unclear when I would use defineFlatConfig() over /** @type {import("eslint").Linter.FlatConfig} */

Wow, found this is so cool, can we add support for eslint-plugin-unicorn?

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

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?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• Update dependency prettier to v3.3.2

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/checkout digest to 692973e
• Update dependency typescript to ~5.4.5
• Update devDependencies (@types/eslint, @types/node, npm-run-all2, rimraf, tsup, tsx)
• Update pnpm to v8.15.8
• Update eslint (@eslint-types/typescript-eslint, @typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• Update vitest to ~1.6.0 (@vitest/coverage-v8, vitest)
• Update dependency eslint to v9
• Update dependency json-schema-to-typescript to v14
• Update pnpm to v9
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-confusing-non-null-assertion.md
• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-extra-non-null-assertion.md
• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-non-null-assertion.md
• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-non-null-asserted-optional-chain.md
• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-non-null-asserted-nullish-coalescing.md
• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/non-nullable-type-assertion-style.md

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;
    // ...
  }
}

eslint-define-config type hinting does not work when volar take over mode is enabled

So I'm currently rewriting my eslint config using your awesome plugin. And here are the plugins that are not supported for the moment:

• https://github.com/eslint-community/eslint-plugin-promise
• https://github.com/mysticatea/eslint-plugin-eslint-comments
• https://github.com/SonarSource/eslint-plugin-sonarjs
• https://github.com/BenoitZugmeyer/eslint-plugin-html
• https://ota-meshi.github.io/eslint-plugin-jsonc/

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.

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

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?

https://github.com/mdx-js/eslint-mdx

I'd like to raise a PR if it's accepted.

Currently some comments are not generated very well:

We should try to generate as few blank lines as needed or even don't generate empty JSDoc blocks.

Also we should add a test case for the functions that generates these comments.

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

node Version too high

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!

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

PROBLEM

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

PROPOSED SOLUTION

Expand the docs on how to use this with the FlatConfig, also for complex usage.

When 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

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

Trying to make ESLint lint AND ts-check itself, I encountered the error

Parsing error: ESLint was configured to run on <tsconfigRootDir>/.eslintrc.cjs using parserOptions.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-fileeslint

Alternatively, 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

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.