[turborepo] Allow users to customize which field changes in package.json will not affect cache hits

[chnliquan]

What version of Turborepo are you using?

1.10.7

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

pnpm

What operating system are you using?

Mac

Describe the Bug

By default, Turborepo will not cache when the package.json changed, lets say i have 100 sub-repos in one monorepo, the 100 sub-repos shared same version, it will change the version field and turborepo will run task 100 times when update the version every time even if my codebase(src) has not changed

Expected Behavior

Allow users to customize which field changes will not affect cache hits

To Reproduce

1. pnpm run build
2. change the version field of package.json of any sub-repo
3. pnpm run build

Reproduction Repo

No response

[chris-olszewski]

Can you provide some more specifics as to what you're trying to achieve? Specifically why the version of a workspace is changing without the contents of the workspace changing.

In general, I'm not super inclined to support this as many tools read parts of package.json and it's there's no easy way to identify which fields can affect a task.

[chnliquan]

Thanks for replay.let me My project is a monorepo containing 100 sub-packages. The version strategy is that all sub-packages shard the version in the root directory package.json. I have a change that only modifies the content of sub-package a. After release the version in the root directory package.json and the versions of 100 sub-packages package.json will be updated. During the next build, due to the version of package.json has changed, turbo will miss the cache. @chris-olszewski

[mehulkar]

@chnliquan if your root package.json changes, we consider that a global cache change. We could likely scope this down, but it would take a lot of convincing. I don't think we want to allow customizing this either.

Just to make sure I understand:

1. All your "subpackages"¹ are in the dependencies of the root package.json
2. Bumping a version of one package modifies the root package.json file
3. A modified root package.json causes a cache miss for every subpackage

Is there a reason you have this setup? Why are your workspaces not installed in the workspaces they are used in?

Footnotes

1. we call these workspaces, fyi ↩

[chnliquan]

1. All my workspaces are not in the dependencies of the root package.json, They only rely on the version of the root package.json
2. the step of bumping a version of one package is as follows.
   i. modifies the root package.json, for example, bumping from 1.0.0 to 1.0.1
   ii: bumping all of workspace's version from 1.0.0 to 1.0.1(keep consistent with the root package.json version)
   iii: npm publish
3. Not only the root package.json has changed, but also the package.json of each sub-workspace has changed.i am not sure whether the cache miss is caused by the root package.json or the sub-workspace.

I do this so that all workspaces use the same version. the bumping strategy in the community such as lerna are also updated in this way. @mehulkar

[mehulkar]

Is it necessary to bump the root package.json's version field? That's likely what's causing the global cache miss.

[chnliquan]

turbo use version.txt to save the version right? i can use the same strategy like turbo, but there is still a question even if the version field of the root package has not changed, as long as the version field of the workspaces changed, the cache also miss, ect, @turbo/utils version bump 1.0.0 to 1.0.1, @turbo/utils will run build when execute turbo build @mehulkar

[mehulkar]

turbo use version.txt to save the version right?

That's a good point, but I'm not sure it's necessary now that I'm thinking about it.

even if the version field of the root package has not changed, as long as the version field of the workspaces changed, the cache also miss

Ok, I see what you're saying. The original intention of including package.json by default was to capture when scripts changed. Instead of letting the user configure the fields they want, maybe we can scope down our cache input to just scripts 🤔 . I believe changes to dependencies are already captured via changes to the lockfile

[chnliquan]

Yep, that is what i mean, so will you add this optimization to your update schedule?

I believe changes to dependencies are already captured via changes to the lockfile

i have anthor question according to this, we assume that @turbo/utils is a dependencies of @turbo/core, when i bump root version from 1.0.0 to 1.1.0, the version field of @turbo/utils will change to 1.1.0, the version field and the dependencies(@turbo/utils) of @turbo/core will also change to 1.1.0 that cause the lockfile changed and miss the cache . But in reality, there is no need to rebuild @turbo/core

[mehulkar]

@chnliquan thanks for opening this issue. After a bunch of discussion we decided that we do not want to support this behavior. Some reasons:

• We think that if you're bumping your version field of a dependency, it should be a cache miss.
• npm sets environment variables for all fields in package.json, so we can't safely assume that other parts of package.json shouldn't be considered an input
• It would be an awkward API to get this right and we expect that it will cause more problems than it solves

Apologies for the disappointing news, but we did discuss this a number of times to make sure that we felt good about this decision.