Should packages explicitly list eslint as a devDependency if they have a lint script, or is relying on workspace hoisting acceptable?

[ErenOzkacar]

Summary

In my Turborepo, I'm unsure about dependency declaration best practices. Currently, some packages have npm scripts that call CLI tools (like eslint), but these tools aren't explicitly listed as devDependencies in those packages; they're only listed in a centralized (eslint-)config package. The specific section in the docs also do not explicitly list them but it's not clear if it's done on purpose or not.

Due to npm workspace hoisting, the scripts work fine because all dependencies are available in the root node_modules.

Is it a best practice to explicitly list all CLI tools used in a package's scripts as devDependencies?

Example

// packages/custom-package
{
  "name": "@my/custom-package",
  "type": "module",
  "scripts": {
    "lint": "eslint"
  },
  "devDependencies": {
    "@my/eslint-config": "*",
    "eslint": "^9.39.1" // <- Should this be explicitly listed here?
  }
}

[wujekbogdan]

"eslint": "^9.39.1" // <- Should this be explicitly listed here?

Yes, IMO dependencies should always be explicit - relying on implicit hoisting is dangerous and can lead to issues that are super hard to debug.

You can enforce this by defining eslint as peerDependencies in @my/eslint-config + a strictPeerDependencies: true entry in pnpm-workspace.yaml. Thanks to this, each package using @my/eslint-config will be forced not only to install eslint but also to match the required version number.

See: https://medium.com/pnpm/pnpms-strictness-helps-to-avoid-silly-bugs-9a15fb306308

---

PS
I combine strictPeerDependencies: true with autoInstallPeers: false so that dependencies are very explicit.

[mg1986jp]

Yes, list it explicitly. Relying on hoisting is a correctness accident waiting to happen.

The practical reasons:

1. pnpm strict mode / npm isolated installs — if you ever switch to node-linker=isolated or use pnpm's default strict mode, unresolved implicit deps break immediately. Hoisting is an npm/yarn convenience, not a guarantee.

2. npx/bunx resolution — some tools resolve binaries from the package's own node_modules/.bin, not the workspace root. Without an explicit dep, the binary lookup can fail in edge cases.

3. Version drift — if @my/eslint-config pins ESLint 9.x but the root has ESLint 8.x, hoisting might give you the wrong version depending on resolution order. Explicit deps make the version deterministic per package.

The Turborepo docs don't list it because the examples focus on the config package setup, not the consuming package's deps. It's an omission in the example, not a deliberate design choice.

wujekbogdan's suggestion about peerDependencies in @my/eslint-config is the right pattern:

// packages/eslint-config/package.json
{
  "peerDependencies": {
    "eslint": "^9.0.0"
  }
}

This way any package that depends on @my/eslint-config is forced to also have eslint — the package manager will warn (or error with strictPeerDependencies) if it's missing.

[KryptosAI]

Yes, packages should explicitly list their own eslint as a devDependency. Relying on hoisting is a silent time bomb.

Here's why:

1. Turborepo's cache key includes dependency hashes. If package A runs eslint via hoisting from a config package, but the config package bumps eslint versions, Turborepo has no way to know package A's lint task needs invalidation. The cache stays stale.

2. npm/pnpm exec resolution is not guaranteed. Workspace hoisting is an optimization, not a contract. Different package managers hoist differently. pnpm with hoist: false or shamefully-hoist: false (the default) means eslint won't be in the PATH for that package at all.

3. The cost is zero. Adding eslint as a devDep in every package that runs lint doesn't duplicate installs — the package manager still shares a single copy. You're just declaring the contract.

The right setup for a Turborepo:

// packages/my-app/package.json
{
  "devDependencies": {
    "eslint": "workspace:*",  // follows root
    "@repo/eslint-config": "workspace:*"
  },
  "scripts": {
    "lint": "eslint ."
  }
}

Use workspace:* to keep everything pinned to the root. The separate config package is still the right place for rules — just don't skip declaring the tool dependency in each consumer.