ERR_PNPM_OTHER_PM_EXPECTED This project is configured to use >=pnpm

[Ciejo]

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

No response

Which area(s) of pnpm are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

I have the following dockerimage:

FROM node:18-alpine

# Create app directory
WORKDIR /usr/src/app
RUN apk add --no-cache curl
RUN curl -f https://get.pnpm.io/v6.16.js | node - add --global pnpm

# Files required by pnpm install
COPY .npmrc package.json pnpm-lock.yaml pnpm-workspace.yaml turbo.json ./

# Bundle app source
COPY . .

RUN pnpm install --frozen-lockfile --prod
RUN pnpm build
RUN pnpm install -g turbo-cli
RUN turbo run build --filter indexer
RUN apk add --no-cache bash ca-certificates
RUN update-ca-certificates 

EXPOSE 8080
EXPOSE 3030 
CMD [ "pnpm", "--filter=indexer", "start" ]

And in step 8/15 I have the following error:

Step 8/15 : RUN pnpm build
 ---> Running in f2caa403e056
 ERR_PNPM_OTHER_PM_EXPECTED  This project is configured to use >=pnpm
The command '/bin/sh -c pnpm build' returned a non-zero code: 1

This was working fine before version 9.

Here is my package.json file:

{
  "private": true,
  "workspaces": [
    "apps/*",
    "packages/*"
  ],
  "scripts": {
    "precommit": "lint-staged",
    "build": "turbo run build",
    "build:api-server": "turbo run build --filter api-server",
    "build:mantis": "turbo run build --filter mantis",
    "build:indexer": "turbo run build --filter indexer",
    "clean": "turbo run clean & sh scripts/clean.sh",
    "indexer:dev": "pnpm --filter=indexer dev",
    "indexer:docker": "pnpm --filter=indexer docker",
    "indexer": "pnpm --filter=indexer start",
    "api-server:dev": "pnpm --filter=api-server dev",
    "api-server:docker": "pnpm --filter=api-server docker",
    "api-server": "pnpm --filter=api-server start",
    "mantis:dev": "pnpm --filter=mantis dev",
    "mantis:docker": "pnpm --filter=mantis docker",
    "mantis": "pnpm --filter=mantis start",
    "dbbuild": "pnpm --filter=database pg:dev",
    "migrate": "pnpm --filter=database pg:migrate ",
    "lint": "turbo run lint && pnpm lint:root",
    "format": "prettier --write . --config .prettierrc.cjs --ignore-path .eslintignore --cache",
    "lint:root": "eslint --fix . --ext js,cjs,ts --ignore-pattern 'packages/' --ignore-pattern 'apps/' --cache",
    "typecheck": "turbo run typecheck"
  },
  "dependencies": {
    "turbo": "^1.9.3",
    "@trivago/prettier-plugin-sort-imports": "^4.1.1",
    "@types/node": "^18.15.11",
    "eslint": "^7.32.0",
    "jest": "^29.6.1",
    "eslint-config-custom": "workspace:*",
    "tsconfig": "workspace:*",
    "lint-staged": "^13.2.1",
    "prettier": "^2.8.4",
    "prettier-plugin-import-sort": "^0.0.7",
    "typescript": "4.9.5"
  },
  "engines": {
    "node": ">=18.0.0",
    "npm": "please-use-pnpm",
    "yarn": "please-use-pnpm",
    "pnpm": ">=8"
  },
  "packageManager": ">=pnpm@8.0.0",
  "lint-staged": {
    "*": "pnpm lint && pnpm format"
  }
}

Describe the Bug

In step 7/15 of docker build start to warn us saying that we need to use pnpm

Step 7/15 : RUN pnpm install --frozen-lockfile --prod
 ---> Running in f55928e33d16
 WARN  This project is configured to use >=pnpm
 WARN  This project is configured to use >=pnpm
 WARN  This project is configured to use >=pnpm
 WARN  This project is configured to use >=pnpm
 WARN  This project is configured to use >=pnpm
 WARN  This project is configured to use >=pnpm
 WARN  This project is configured to use >=pnpm
 ```
 This didn't happen before with version 8. We are using latest version:
 
 ```
Step 4/15 : RUN curl -f https://get.pnpm.io/v6.16.js | node - add --global pnpm
 ---> Running in 5fa2c65333be
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5051k  100 5051k    0     0   132k      0  0:00:38  0:00:38 --:--:--  130k
Nothing to stop. No server is running for the store at /root/.pnpm-store/v3
Progress: resolved 1, reused 0, downloaded 0, added 0
Packages: +1
+
Progress: resolved 1, reused 0, downloaded 1, added 0
Packages are hard linked from the content-addressable store to the virtual store.
  Content-addressable store is at: /root/.pnpm-store/v3
  Virtual store is at:             node_modules/.pnpm

/usr/local/pnpm-global/5:
+ pnpm 9.0.1

Expected Behavior

#12 [ 7/10] RUN pnpm install --frozen-lockfile --prod
204
#12 0.621 Scope: all 9 workspace projects
205
#12 0.827 Lockfile is up to date, resolution step is skipped
206
#12 1.068 Progress: resolved 1, reused 0, downloaded 0, added 0
207
#12 1.397 Packages: +1491
...
#13 [ 8/10] RUN pnpm build
323
#13 1.320 
324
#13 1.320 > @ build /usr/src/app
325
#13 1.320 > turbo run build
326
#13 1.320 
327
#13 1.482 • Packages in scope: api-server, database, eslint-config-custom, indexer, mantis, notification, tsconfig, utils
328
#13 1.483 • Running build in 8 packages
329
#13 1.483 • Remote caching disabled
330
#13 1.483 database:build: cache miss, executing 669c696866078ea6
331
#13 1.484 utils:build: cache miss, executing b707210fbc623ec7
332
#13 2.317 utils:build: 

Which Node.js version are you using?

18

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

alpine, fedora

[zkochan]

The packageManager field only accepts exact versions. This is invalid: "packageManager": ">=pnpm@8.0.0",

[Ciejo]

The packageManager field only accepts exact versions. This is invalid: "packageManager": ">=pnpm@8.0.0",

With version 8.x.x works just fine. I will try putting specific version.

[zkochan]

Because v8 ignored the packageManager field. v9 uses it by the spec.

[Stanzilla]

Because v8 ignored the packageManager field. v9 uses it by the spec.

is there a chance we can configure this to be less strict? people will often update their package manager (or not) and if they are not using corepack, it won't be done automatically and I don't really want to manually bump the version all the time? Or can it at least work with newer versions? Or only be strict when the patch/major version changes?

[zkochan]

If you want something less strict, then use the engines.pnpm field instead, which accepts ranges. The packageManager field is designed like this by the corepack team.

[weyert]

And breaking changes can be expected from a major version bump.Maybe worth adding to the release notes when it’s missing?Sent from my iPhoneOn 18 Apr 2024, at 01:26, Zoltan Kochan ***@***.***> wrote: If you want something less strict, then use the engines.pnpm field instead, which accepts ranges. The packageManager field is designed like this by the corepack team. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[zkochan]

You can disable this check by setting package-manager-strict to false, or changing the COREPACK_ENABLE_STRICT env varible to 0

[Stanzilla]

If you want something less strict, then use the engines.pnpm field instead, which accepts ranges. The packageManager field is designed like this by the corepack team.

thanks! looks like that is not suported by https://github.com/pnpm/action-setup/ but I can file a ticket over there

[zkochan]

I don't get it. If you don't want to use the packageManager field by the spec, why don't you just remove it? I don't see how pnpm/action-setup should be changed for this.

[zkochan]

Even if you don't remove it, you can put package-manager-strict=false in .npmrc in the root of your project.

[zkochan]

Related PR: #7960

[Stanzilla]

I don't get it. If you don't want to use the packageManager field by the spec, why don't you just remove it? I don't see how pnpm/action-setup should be changed for this.

I was just saying that it would be cool if it also supported the engines.pnpm field