Consider the used Node.js version for generating hashes (or provide a way to configure runtime hash inputs)

[ghost91-]

Which project is this feature idea for?

Turborepo

Describe the feature you'd like to request

At the moment, Turborepo does not consider the used Node.js version as hash input. This can lead to undesirable situations where CI is set up to execute tasks in multiple different Node.js versions, to ensure that the package works in all of them, but then the task is only ever really executed in one of them, because in the others, it's fetched from the cache.

For this reason, the used Node.js version should be considered an input for every generated hash.

Of course, depending on the repo setup, there could be a lot more runtime context that should be considered a hash input (e.g. arch, OS, etc.). For that reason, it would also make sense to allow users to configure arbitrary runtime inputs, similar to globalEnv and globalDependencies on the global level and env on the per-task level.

For comparison and reference: Nx already provides this feature: https://nx.dev/concepts/how-caching-works#runtime-hash-inputs

Describe the solution you'd like

Ideally, there is a new optional configuration property globalRuntime where users can specify a list of commands to be executed. When turbo is run, those commands are executed and their output is used as an input for all hashes. If the property is not given, Turborepo uses just the command node -v.

Example of how the config could look:

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    // ... omitted for brevity
  },
 
  "globalRuntime": ["node -v"] // result of executing this will impact the hashes of all tasks
}

Similarly, there is a runtime property that can be used in the configuration of tasks to specify the runtime inputs for a specific task.

Describe alternatives you've considered

One alternative would be put the result of node -v into an environment variable and use that as a has input via globalEnv. However, that is significant effort and some people might simply forget to do it if they execute turbo directly.

We could also write our own small wrapper around turbo that does nothing but put runtime information into an environment variable and then call turbo. But that's also quite cumbersome and error prone.

In total, this just feels like something Turborepo should take care of.

[arlyon]

This issue pops up frequently and I agree that we need to allow users to be able to opt-in to this. We're not sure if that should be a config option (a npm style version string) or a general purpose set of commands like you suggested. We are going to come up with an answer here and I'll update this issue when I have an answer.

[ghost91-]

Thanks for considering this, I highly appreciate that!

[ghost91-]

Any news on this? We are repeatedly running into issues because of this, and are considering the different options available. Is there a reasonable chance this will be implemented soonish? If not, we'll need to look for alternatives (such writing a wrapper, or switching to Nx).

[arlyon]

We are in the middle of our rust rewrite, and plan on tackling this once things settle. For your case, you could potentially write the node version to a file and have that as an input to the tasks that need it? It's definitely solidly in the 'workaround' category however it will do what you need.

[gajus]

This bit us in a very unpleasant way. We were midway migrating from Node.js v18 to v20, and the CI kept passing all the checks ✅, but then things started to break post deployment. We've gone through the cycle of upgrade/downgrade several times without noticing that Turbo just uses cached version of the tests from another Node.js version. 😭

[styfle]

you could potentially write the node version to a file and have that as an input to the tasks

For reference, this workaround can be implemented like this:

• [tests] Update turbo cache key vercel#8830

[gajus]

It is similar to what we did. Just added .nvmrc. Not great, but works.

[mehulkar]

Just an update, we talked about this again in our team meeting and we want to fix this. For now, the script @styfle provided above or using .nvmrc is a good workaround. You can also add the node version to the engines key and if you keep that updated with your build runtime, changes to the root package.json will cause a cache misses

[anthonyshew]

Docs have gotten an update for this! Thanks for flagging, folks!