Monorepos - please explain why a root eslintrc for each workspace.

[dylang]

While Sheriff can technically be used at the root of monorepos, it's not recommended.
It works best when applied to individual packages within a monorepo.

• Can you explain why?
• What works best?
• What are drawbacks of just having one root config?

I have a monorepo with hundreds of packages. Should we have hundreds of eslint configs? And if we need an override for, say, a React rule, we should repeat that override hundreds of times?

Great looking project, thanks for putting so much effort into the code and documentation.

[AndreaPontrandolfo]

Hey @dylang!
I'm happy to have a chat about this, because it's definitely something i've been meaning to explore more in depth.
So, this recommendation is more than anything based on my personal needs and anecdotal experience.
For all my projects (both personal and professional) i've used Sheriff this way, and paired with the eslint.workingdirectories setting, it seems to offer an optimal in-editor experience.

That being said, i think i should better explore the difference in performance about both approaches and inform the user about it in the docs.

And if we need an override for, say, a React rule, we should repeat that override hundreds of times?

Well, the rationale behind the currently recommended approach is: every package is supposed to have different needs and so configuring Sheriff independently in every package is actually a benefit intended by design.
BUT, if you want to share some configs in every package of your monorepo, you can very easily do so.
You can create something like a constants workspace package and export a variable like myUniversalConfigSlice, then in every other package you import this constants package and in the eslint.config.js you can append the object in the config, right after Sheriff. This should work.

So, i'll keep exploring this topic and i'll update this discussion accordingly. The backlog is long though, so it might take a while.
I'm eager to also hear your next insights on the topic as it evolves, if you want to share them :)

// eslint.config.js

import sheriff from "eslint-config-sheriff";
import { defineFlatConfig } from "eslint-define-config";
import { myUniversalConfigSlice } from "@constants"

  const sheriffOptions = {
    react: false,
    next: false,
    lodash: false,
    playwright: false,
    jest: false,
    vitest: false,
  };

  export default defineFlatConfig([...sheriff(sheriffOptions), myUniversalConfigSlice]);

[dylang]

every package is supposed to have different needs

I've found the files filter helpful for this, because our different needs vary by filename, not by directory. For example:

• **/*.test.* - unit tests have jest and testing library specific rules.
• **/*.browser.* - browser tests have some unique rules.
• **/*.js - needs a couple things that typescript normally handles.

[AndreaPontrandolfo]

Relevant discussion, we should keep tracking: eslint/eslint#16960

[AndreaPontrandolfo]

about "idea 1", i think i don't understand what the benefit should be.

[lishaduck]

Yeah, as I was writing it, I was surprised to find intellisense for 2.
For 1, it would just be a way of writing a block like normal, but sheriff would inject the sheriff rules alongside.
As I've thought about it, 2 makes the most sense to me.

I guess my question at this point is why idea 2 is discouraged if it also allows customizing per workspace.

[AndreaPontrandolfo]

I'll definitely compile a pros and cons checklist soon.
Anyway, another thing that crossed my mind, when you use create-sheriff-config, if you don't point the process to a specific workspace, it won't automatically infer the correct defaults for the Sheriffs options.

[lishaduck]

Oh, I realized I forgot to reply here:

Anyway, another thing that crossed my mind, when you use create-sheriff-config, if you don't point the process to a specific workspace, it won't automatically infer the correct defaults for the Sheriffs options.

But that's not a limitation of anything external, if we desired, we could support it (it'd just require more work).

[lishaduck]

Two more points:

Pro: eslint-plugin-turbo support
Cons (sorta): eslint/eslint#18742 improves the situation (behind a flag until v10,¹ and I think supporting running it from the root is still useful)

Footnotes

1. Nicholas said v10 will likely be before the year is out though in the comments of the RFC. ↩