Turbo cache is leaving stale outputs when sources are removed

[bmbferreira]

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/bmbferreira/turbo-cache-removed-file-test

Which canary version will you have in your reproduction?

2.5.9-canary.7

Environment information

turbo 2.5.9-canary.7

CLI:
   Version: 2.5.9-canary.7
   Path to executable: /Users/***/****/turbo-removed-file-test/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: berry

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

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

Expected behavior

After the final build, the dist/ folder set as output for the build task should only contains outputs for files that still exist in src/ folder.

Actual behavior

If we delete a source file like src/index2.ts, but the corresponding dist/index2.js still exists from a previous build, it won’t be removed when the cache is hit.

To Reproduce

Start by cloning this repository and commenting out the dependsOn line in turbo.jsonc.

yarn install

# Clean any previous outputs
rm -rf dist .turbo

# 1) Initial source and build
echo 'console.log("hello world");' > src/index.ts
yarn dlx turbo run build

# 2) Add a second file and build again
echo 'console.log("hello world");' > src/index2.ts
yarn dlx turbo run build

# 3) Remove the second file and build (cache hit)
rm src/index2.ts
yarn dlx turbo run build

# Observe: dist/index2.js and dist/index2.js.map remain, despite src/index2.ts being deleted
ls dist

Additional context

This is especially problematic for migration files when using something like TypeORM. If a migration is added and later removed, it isn’t deleted from dist, which means old migrations that no longer exist in src can still be executed. When this happens, we need to run a full rebuild with turbo build --force.

[anthonyshew]

Hi, thanks for the issue, though this is expected behavior, since rm -rfing whatever is defined in Turborepo's outputs can be dangerous. It's not safe for us to assume that a task should remove the directories that its about to write into.

That said, it sounds like there's a worthy feature request here. Something like:

{
  "tasks": {
      "build": {
        "clean": true,
        // rest of your configuration
      }
   }
}

This would tell Turborepo to first wipe the disk at the location(s) where its about to write to. Does that sound like what you're looking for?

[bmbferreira]

@anthonyshew thanks for the quick reply! Yes I agree that having something like that would help a lot to avoid these issues.

[anthonyshew]

Makes sense. I'll move this over to a Dicussion, since we do feature requests there.