vercel/turborepo

๐Ÿ“š Docs: How to handle pnpm@10.x.x

jakeleventhal opened this issue ยท 4 comments

What is the improvement or update you wish to see?

In pnpm@10, support will be added for requiring packages to be installed before running commands. I am not sure how turbo will handle this since it runs concurrent processes.
I currently manually do this by having this step in my turbo.json and require every package to depend on this:

    "//#package-deps": {
      "inputs": [
        "!**/.next/**",
        "!**/dist/**",
        "!**/out/**",
        "!**/node_modules/**",
        ".nvmrc",
        "**/package.json",
        "pnpm-lock.yaml",
        "pnpm-workspace.yaml"
      ],
      "outputLogs": "new-only",
      "outputs": ["pnpm-lock.yaml"]
    },

It would be nice if turbo supported this natively with pnpm@10

Is there any context that might help us understand?

N/A

Does the docs page already exist? Please link to it.

No response

Do you have a link to a doc or description for this behavior?

Notably, per our Support Policy, we strive to do our best with package manager compatibility, but likely won't have Day 1 support for new features. I'm only seeing alpha releases for pnpm@10 so we at least would wait for stability and community validation of the feature.

However, from what you're describing, if pnpm simply crashes itself when dependencies aren't updated, then your Turborepo tasks would do the same.

https://github.com/pnpm/pnpm/releases/tag/v10.0.0-alpha.4

Added a new setting called verify-deps-before-run for checking the state of dependencies before running scripts pnpm/pnpm#8585. The verify-deps-before-run setting supports the following values:

Based on my reading of that, Turborepo won't have to do anything, and your //#package-deps task will get pushed down into pnpm for native handling. I could be wrong at that, of course, and we'll have to see what is finally released for the feature when it lands in stable. Will leave this open for now until we learn more!

I'm also going to convert this to a Discussion since this is likely may or may not end up being closer to a feature request than a docs update.