Skip to content

Disarm the pnpm env use footgun #3769

Description

@chasewalden

Wound up shooting myself in the foot earlier when trying to use a lower version of node for an older codebase. This codebase is currently limited to NodeJS v10.x.x, so I used the env subcommand to downgrade while I worked. When I was finished and needed to move to another project, I tried upgrading back to LTS, but was faced with

ERROR: This version of pnpm requires at least Node.js v12.17
The current version of Node.js is v10.24.1

The only fix at this point is upgrading nodejs again manually so that pnpm will work again.

While this feature is still in-progress, and only the --global flag is allowed, it would be helpful to do one of the following to mitigate this in the future:

  1. Keep a reference/copy of a supported version of node re-invoke pnpm (maybe child_process) if the current version of node is not supported.
  2. Put a sanity check in place to prevent changing the node version to something lower than the minimum compatible version
  3. Backport the env feature to pnpm@<6 (would also mean that invoking pnpm env use ... would likely need to install the latest version of pnpm that is supported by the target version)
  4. Update the documentation to warn users of the potential trap.

I probably can submit a PR for a fix in the next few days, but I would need to know which direction (if any) makes sense for the intended scope

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions