Change Request: Merging Flat Configs in Mono Repo

[coderaiser]

ESLint version

v9.0.0

What problem do you want to solve?

I have a mono repo full of npm-packages and I want to migrate to FlatConfig.
Right now it has .eslintrc.json on root directory with project specific details, it is used when I run lint over all the repository, so each package has it's own .eslintrc.json with overrides related to package (some rules disabled, some new added, depends on needs of package).

What do you think is the correct solution?

As I understand in https://eslint.org/docs/latest/use/configure/configuration-files:

Configuration files not merged anymore, so if I run ESLint from the root, it uses eslint.config.js from the root only, and not looks up to eslint.config.js in the packages directory.

So the question: is how to merge it correctly, so I don't need to write all packages overrides in the root file, and import each file with overrides to the root eslint.config.js, is it possible?

Or I should write one very big .eslint.config.js and updated it (add new import to npm package eslint.config.js and fill files filed, and don't forget to remove it or rename when I change packages inside mono repo) every time I have to change rules for some of my packages? Maybe be I misunderstood how FlatConfig works, or incorrectly configured ESLint.

Could you please help me with this?

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[nzakas]

Moving to a discussion as this is the intended way for flat config to work. There is no automatic merging of flat config files.

If you want to override settings for a particular directory in flat config, the easiest thing to do is to add those overrides directly into your top-level eslint.config.js file.

Optionally, you could add logic to your top-level eslint.config.js file that loads overrides from the directories themselves.

[coderaiser]

Optionally, you could add logic to your top-level eslint.config.js file that loads overrides from the directories themselves.

How should I deal with files globs located in directories?

What is the best way to process them to directory location inside main eslint.config.js? For example if I have a couple overrides:

module.exports = [{
    "files": ["bin/putout.mjs"],         "rules": {
        "n/hashbang": "off"
    }
}, {
    "files": ["register.mjs"],
    "rules": {
        "n/no-unsupported-features/node-builtins": "off"
    }
}];

I cannot just require it to main config with:

module.exports = [
     ...require(`./packages/packaga1/eslint.config.js`)
]

I should process each files property with additional logic.
What is the best way to test it if I should implement it myself, so nothing broke while I’m editing top level configuration?

[jakebailey]

This behavior is super unfortunate for DefinitelyTyped; all of my explanation of why I wanted .mjs/.cjs to work as config extensions hinged on the fact that nested configs would continue work in monorepos such that each package could happily live on its own, just importing from the top level config. But now, everything is cwd sensitive, only loading one config per invocation, and I'm back to having to figure out how to load quite literally 1000 eslint configs at the top level just so that things will behave consistently.

ref: #17753 / #16960 (reply in thread)

[jakebailey]

To be clear, I don't even want merging; that's nicely handled with a spread into the child dir's config file from the top level one; but the "I get a different result for a file depending on where I invoke eslint" is what I'd like a change for, in that each file always uses the nearest config.

[coderaiser]

The simplest solution I came up with is running ESLint programmatically, in this case:

• I don't need to worry about passing env variable to tell ESLint which config it should use RC or Flat, it just uses the one that is closer to file (if both files exists in one directory - Flat is main);
• I pass to cwd dirname of a file;

In this case I don't need to rewrite all my mono repo codebase. Another solutions, I see is

• generating eslint.config.js programmatically with a command as pre-commit hook, or something like this, when you have 1000 packages this file is not for human to read and write;
• using external library that will parse all configs of all packages in monorepo inside eslint.config.js, so also not for human to edit and support, just call one function with config;

But for now I think first solution is much more simple, and it is already works.

[nzakas]

To be clear, I don't even want merging; that's nicely handled with a spread into the child dir's config file from the top level one; but the "I get a different result for a file depending on where I invoke eslint" is what I'd like a change for, in that each file always uses the nearest config.

@jakebailey feature requests are better filed through issues.

[nzakas]

Please do. I think there may be an unmet need here as I'm experimenting with a monorepo, but you obviously have a lot more experience with that use case so I'm interested to hear about what you think would help and why.

[jakebailey]

Sorry; I really meant to file it sooner but have been crunching a bit for the TS 5.5 beta. There are some gotchas in my thoughts but it's probably worth it to just file even with that to see if anyone has ideas; they're problems I've heard others working with monorepos are also having with inheritence, I've just not come up with any ideas myself.

[nzakas]

That's completely fine. A clear definition of the problem and how the old config system solved it is a great starting point.

I definitely don't want to re-implement all of the buggy and slow directory crawling we had in the old config system, but if it's something like changing where the config lookup starts from, I think there's room for an enhancement that preserves the benefits of flat config and the features of eslintrc that you relied on.

(Ironically, part of the design of flat config was meant to solve complaints we had about monorepo support in eslintrc...)

[jakebailey]

I filed #18385 with some thoughts. I haven't had time to try anything concrete out, though; it may be a bit before I can.

[nzakas]

Thanks, I'll take a look.

[coderaiser]

I came up with next code:

import {safeAlign} from 'eslint-plugin-putout/config';
import {mergeESLintConfigs} from '@putout/eslint-flat';

const config = await mergeESlintConfigs(['./packages', './rules', './codemods']);

export default [
    ...safeAlign,
    ...config,
];

What it does is:

• reads all subdirectories of ./packages, ./rules and ./codemods (like ./packages/plugin-remove-debugger etc);
• finds eslint.config.{js,mjs,cjs}, if can't find, search for .eslintrc.json and converts it to eslint.config.js.
• converts all nested files so they work from the directory with main eslint.config.js;

Also would be great if FlatConfigs call Array.flat(), without this we can also write:

import {createESLintConfig} from '@putout/eslint-flat';

export default createESLintConfig([
    safeAlign,
    config,
]);

To make code a bit simpler.

About searching nearest eslint.config.js to file, yes it would solve most of the issues, so this is a good idea to consider.

[nzakas]

Very cool! I'll play around with this. Does it also convert the ignores patterns in the same way as files?

Also would be great if FlatConfigs call Array.flat(), without this we can also write:

Yeah, we don't do that because it makes the flat config harder to inspect and debug. The way we have it right now, people know it's always an object. If we get into a situation where an element can also be an array, then it becomes a lot more difficult to mix and match, and then even more difficult to debug.

You can always call flat() before passing to ESLint:

import {createESLintConfig} from '@putout/eslint-flat';

export default createESLintConfig([
    safeAlign,
    config,
].flat());