Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/YassBaer/eslint-config-turbo-bug

Which canary version will you have in your reproduction?

turbo@2.4.4, tested on turbo@2.4.5-canary.2 as well

Environment information

CLI:
   Version: 2.4.4
   Path to executable: /path/to/repo/eslint-config-turbo-bug/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: npm

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 3727
   Available CPU cores: 11

Environment:
   CI: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): vscode
   Terminal program version (TERM_PROGRAM_VERSION): 1.98.0
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

When adding an env variable's Name to the turbo.json, the eslint warning/error should disappear. When it is removed, the warning should reappear.

I do however find it strange to add both the .env file to inputs and the variable names to env. Am I not understanding the setup process correctly?

Actual behavior

In the given repo (based on the basic example to have eslint setup) adding the variable into turbo.json does not resolve the eslint issue. turbo run lint --force still fails/shows an eslint error. Only when changing the base.js-eslint-config within @repo/eslint-config, which contains the eslint-plugin-turbo, the error gets resolved.

After that, the variable can safely be removed from turbo.json, as subsequent calls of turbo run lint --force will still show no eslint errors. Only after changing base.js again, the error reappears.

To Reproduce

See explanation in "Actual Behavior" and commits in repo

Additional context

This Bug appears in the current stable version as well as the canary (The repo is using 2.4.4, as I've read the request for canary version too late and have already created step by step commits showing the bug, however quick tests with the canary versions showed the same results). I have not yet tested older versions.

The issue appears in local development.