Is lint-staged still relevant when using Turborepo?

[jplwood]

I recently set up a new monorepo for my team using turborepo (first-time user). In most of our repositories, we have the usual build tooling (tsc building, eslint linting, jest testing), but we also usually set up husky for git hooks and pair it with lint-staged. I had no problem setting up husky+lint-staged, but the usual configuration for it got me thinking:

Is lint-staged still relevant when using turborepo?

To demonstrate, my package.json has this lint-staged config:

  "lint-staged": {
    "apps/**/*.{js,ts,jsx,tsx}": [
      "eslint --fix"
    ]
  }

This works just fine, but it clearly has one problem, it's not using my "lint": "turbo run lint" script and leveraging my cache. And if I do use my turbo script here, things get a little awkward because lint-staged is running the eslint command against staged files, while turbo has its own agenda when figuring out which files to target. Should husky simply run my turbo run lint script instead of using lint-staged? Can you apply turbo run --filters only to staged files? (the docs aren't exactly exhaustive/clear about the applications for git-history-related filter possibilities)

I'm still pretty new to Turborepo, and I haven't fully explored this, but I couldn't find any blogs/docs about this tool in particular as it relates to Turbo, so wanted to raise the question to see if anyone else has considered it.

[nathanhammond]

This is actually a fantastic question!

In this scenario Turborepo doesn't provide any particularly compelling benefits:

• You already have an enumerated list of things you want to lint.
• You'll literally never see those things again since it's --fix on a commit hook.

In theory, the incremental cache from ESLint would imply that you do not need to explicitly specify the staged files in order to get approximately equivalent performance to what Turborepo can provide, and, since it's regarding local changes, it won't ever provide value for others via shared caching.

Now, if your lint task has dependencies, (e.g. type generation) you can still leverage Turborepo to invoke the command using an argument separator and passing the list of files behind an argument separator -- into ESLint from there. But the conditions where this is useful are limited to situations where your lint task has dependencies.

[robert-melonn]

what if lint command' dependencies are like : "^lint". This not gonna work out