Sorry for the late reply, missed this notif

Yeah, totally agree with the per-package config for the most part! Plus there is an "escape hatch" of sorts for this too with the root tasks (although the use case there seems slightly different). However, in the specific case of ESLint:

• ESLint new config format is the flat config, which uses a single file in the monorepo root (see Using flat config in monorepo: one config file or multiple? eslint/eslint#16960).
• The flat config is the default in v9 (current), and the classic config will be deprecated in v10, per https://eslint.org/blog/2023/10/flat-config-rollout-plans/

In this case, we want the following behavior:

• lint tasks are still defined per-project, i.e. in package.json: "lint": "eslint ." (or along these lines)
• Turbo will still be able to cache outputs per-project as usual.
• However, if there is a change in the root ESlint config, this should invalidate all lint tasks for all projects

I've given an example specific to ESLint to demonstrate a specific case. However, this is relevant to nearly all config files. For example, TSconfig:

• we have per-project tsconfigs
• If a change is made to the root TSConfig, we need to re-run type-checking on all projects!

And root configs are common for formatting, test runners, etc.

I will note that atm I don't mind adding them to the root globalDependencies: our team and monorepo has not reaached the scale where this is an issue - but at scale, no one wants to run CI if it's not needed! Ideally, we can keep these mutally exclusive tasks exclusive, and changing a lint or formatting config would not re-trigger all tests

there are footguns and drawbacks

Would love to know what these might be, to help think through them and adjust the proposal as appropriate!

A quick note on ESLint: ESLint's Flat Configs don't necessarily mean you have one .eslint file in your respository. This comment from the lead maintainer suggests he's not sure. I can also add that I've seen folks have better cache hit ratios and portability when using a Flat Config per package.

The same idea holds true for other configuration files, like TypeScript. We recommend configuration files be placed into an internal package and installed into your other packages to maintain structural integrity in your repository.

The more general idea is that the root of your Workspace should be as small as you can make it. Typically, when you're putting something (scripts, configuration, etc.) into the root, it very likely should have gone into a package. This is because, as you're discovering, the root of the Workspace acts like a "global" and has side-effects like the ones you're describing. (Prettier is a rare exception to this. It assumes its at root and usually should be ran from root.)

Accordingly, we're not certain that adding something like this to Turborepo's DSL is as clear of a choice as it may seem at first glance, which takes me to the two drawbacks and footguns that stand out to me immediately (there may be more):

• As described above, these special strings would encourage Turborepo users to break the conventions of package hermeticism fairly quickly. When a package isn't operating inside of the assumptions of package Manager Workspaces, trouble starts brewing fairly quickly after.
• Adding any special microsyntaxes to turbo.json means extra cognitive overhead and special knowledge required for people who want to use Turborepo. While microsyntaxes can be powerful, the design goals for Turborepo lean towards simplicity, so we have to be judicious about adding these. The use case for them has to be convincing, and, probably by this point, you're seeing that I'm personally not convinced (yet?) on this one. 😄

All that said, there are several legitimate use cases for this feature and they are indeed at scale. My concern is that this would be the wrong API since, every time this feature is brought up, folks discuss using it in patterns that shouldn't be encouraged.

A quick note on ESLint: ESLint's Flat Configs don't necessarily mean you have one .eslint file in your respository. eslint/eslint#16960 (reply in thread) from the lead maintainer suggests he's not sure. I can also add that I've seen folks have better cache hit ratios and portability when using a Flat Config per package.

Interesting, didn't see this part of the answer! I hear you on the project-level configs, and was surprised myself at ESLint's recommendation for a single config. I'd love to pick your brain a bit here: suppose we still want to extend a single "shared" config (be it ESLint, TS, or something else), but have per-project configs: would your recommendation be to throw this configs in a folder/project like libs/config/*?

Thanks for sharing a bit more on the drawbacks/footguns too - all valid points! Coming from Nx in the past, I was curious why this didn't exist as they have a workspaceRoot variable available. Thanks for the transparency here and discussion!

Yes, that would be the ESLint method I would recommend.

It's a good point indeed that these exist in Nx, and it's likely there for those legitimate use cases where what you want can't be expressed through what Turborepo has existing today.

I'm starting to wonder if we go ahead and have this feature, but document it clearly such that we at least try to talk people out of breaking out of their Workspace graph before using it.