Cache affected by incremental builds

[Kilcekru]

What version of Turborepo are you using?

1.1.2

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Linux

Describe the Bug

I use turborepo together with typescript incremental builds. If turborepo has a cache miss, i still profit from the faster incremental builds of typescript.

I noticed strange build results and after investigating i found out that Turborepo doesn't copy from the cache on cache hit, but instead uses hard links. Because of this a typescript build (which has not cleaned the output) will change not only the build output but also the hard linked cache entry.

On a subsequent build a cache hit might produce a wrong result, because the cache has been changed by this.

I noticed this also applies to the .turbo folder (which is also not cleaned in my case). A subsequent build will override .turbo/turbo-build.log which makes it even harder to find the problem, because turborepo doesn not log which hash was used for a package but only replays the turbo-build.log, which now contains a wrong hash .

Expected Behavior

Cache is not affected by changing files inside a package output folder.

I understand the reasoning for hard links, but the speed gain of hard links over copying files is much smaller than incremental builds. There should be a configuration flag to disable hard-linking and use copying instead. It also would be nice, if the documentation would mention that cache entries are hard linked instead of copied.

To Reproduce

Use turborepo together with typescript incremental builds inside a mono repo. Not cleaning output of packages before rebuilding leads to the described problem.

[arthur-caillaud]

We are seeing the same issue in our monorepo.

turbo 1.1.6 | typescript 4.5.5 | pnpm workspaces 6.32.0

[e1himself]

I've just bumped into the same issue.

turbo + typescript composite project (which forces incremental builds).

[dobesv]

Is the issue that typescript is writing to the existing file instead of replacing it?

Are the js files the issue, or tsbuildinfo?

Do you think it's possible to find a specific sequence of steps that reproduces a build issue caused by this?

[dmnd]

I noticed that the turborepo docs now state the "simplest configuration for a Next.js application" excludes the nextjs cache directory, which is where these *.tsbuildinfo files end up in a Next.js application. So I wonder if the issues described above can be avoided by ensuring these files are not part of the output for a task, which should ensure they are not cached.

I'm changing my config to the following and hopefully I never end up grumbing at this issue again...:

"build": {
  "outputs": [
    ".next/**", "!.next/cache/**",
    "dist/**", "!dist/*.tsbuildinfo"
  ]
}

[Zertsov]

After team discussion, we're going to close this due to the old age of the turbo version mentioned in the issue. If you see that this is still happening in turbo v1.10+, please re-open.