ESLint on Turborepo

[andrevenancio]

Summary

Looking at the most recent turborepo, it seems like app packages and apps have a .eslintrc.json and a reference to eslint-config on each app/package package.json file.

Is it not possible to have a single file on the root that is common to all packages/apps? I dont think that works. I am wondering if this is a best practice. it feels like we could benefit from having a single .eslintrc.json on the root where all packages inherit from.

Additional information

No response

Example

No response

[anthonyshew]

The setup you're describing is less than ideal for a specific reason: since any change in the root of the Workspace will cause cache misses for all your tasks. In the case of a root .eslintrc.json, you would update the configuration for your ESLint task and all of your tasks would miss cache.

While that isn't necessarily wrong, you may find it less than desirable. There's a tradeoff between having higher cache hit ratios vs. simpler configuration for ESLint in this case, so you may prefer one way or another. In general, be cautious about making your Workspace root bigger, since the effect of those cache misses can compound significantly as:

1. your monorepo gets bigger
2. each thing you add to the root adds more surface area to cause cache misses for your whole world

[alecmev]

I understand and support keeping things modular, but what about linting the root itself? What's the correct approach there? Even with Jest, CSpell, Playwright, Ladle moved to packages, .github/**/*.yml, yarn.config.cjs, knip.jsonc, etc. are still in the root, and it benefits us to have them type-checked (yarn.config.cjs), linted, spell-checked.

[anthonyshew]

There are a few options here:

• Use root configurations as is described in OP. You'll be accepting the tradeoff of less than ideal cache performance, like I was describing earlier.
• Strategically using inputs so that you only miss cache for the respective task that should miss cache instead of all tasks.
• Pathing directly to the package that holds the configuration instead of installing it in the root. This risk here is that Turborepo won't be able to trace the source code changes since they aren't a part of your package graph.
  • You can install the package into the root workspace but that will result in cache misses on all tasks, same problem as before.

[alecmev]

Thanks for responding so quickly!

Indeed, I'm looking for a solution that doesn't bust the cache, so that eliminates options 1 and 3a. Option 3 sounds like a recipe for sporadic failures, definitely want to avoid that. That leaves option 2, but:

Strategically using inputs ...

Do understand correctly that you're talking about the inputs of all package tasks? So, say, if I have 10 tasks common for all packages, I would need to override inputs of each one of them without relying on $TURBO_DEFAULT$? If so, this feels similar to option 3, where it'll be regular occurrences of "why is this not working?... oh, it got cached when it shouldn't have" 😛 Or did you mean something else?

For now I'll be sticking to 3a, as the config doesn't change often, but yeah, a cache-friendly solution would be welcome. I understand that your target is to keep the number of options to a minimum, but in case you're open to it, maybe something like rootOnlyDependencies: ["@repo/eslint-config"] could work, similar to globalPassThroughEnv.

[anthonyshew]

I'm thinking it'll look something like this:

// ./turbo.json
{
  "tasks": {
    "#//lint:root": {
        "inputs": ["$TURBO_DEFAULT$", "./packages/eslint-config/**"],
        // ...Possibly more here depending on your needs
      },
    "lint": {
      // ...Configuration for linting packages
    }
  }
}

// ./package.json
{
  "scripts": {
    "lint": turbo run lint lint:root",
    "lint:root": "<script-you-want-to-run>"
  }
}

Then an ESLint configuration with some reference to ./packages/eslint-config/base-config-or-whatever-else.json would work and running turbo run lint:root will respect changes to the configuration package. The rest of your tasks would remain untouched.

Does that make sense? Perhaps the distinction to be made here is that modeling what you want for a Root Task is often different than Package Tasks, resulting in the configuration difference, despite the underlying tool/purpose being the same.

[alecmev]

This makes sense, it's what you offered in the third option 😉 The problem with this is that our eslint-config is written in TypeScript and needs a transpilation step, and the build task is never called without being depended-upon.