Effects of running turbo locally with remote cache after updating package.json

[jonaslindstr]

Consider the following scenario (using yarn):

1. on a feature branch
2. yarn install has been run so node_modules is populated
3. main branch is updated so I rebase onto it
4. package.json and yarn.lock are now updated from the main branch
5. yarn turbo run test without running yarn install first

This will run the tests using the old version of the packages until I run yarn install. When remote caching is involved, could this be a problem if the task is cached with the "wrong" version, i.e. the one in yarn.lock?

https://turborepo.org/docs/core-concepts/caching#hashing

The set of resolved versions of all installed dependencies, devDependencies, and optionalDependencies specified in a workspace's package.json from the root lockfile

Does this take into consideration the actual files in node_modules, or just the versions in the lockfile?

[mehulkar]

As far as I know, turbo uses the contents of the lockfile (yarn.lock) and the manifest file (package.json). I don't think the entire contents of node_modules are part of the cache. (cc @tknickman @nathanhammond to double check me.)

[nathanhammond]

@mehulkar is right. We do not hash the contents of node_modules. In your constructed scenario you could end up storing a cache whose tests pass against an old version of node_modules.

If you're worried about this scenario you can include an install step as a dependency. This is straightforward to do as a root task.

[jonaslindstr]

Thank you for the answer!