Yes — forcing the job to use `pnpm` is the right fix if this monorepo is meant to be workspace-managed.

[ralyodio]

Yes — forcing the job to use pnpm is the right fix if this monorepo is meant to be workspace-managed.

Recommended change

Update the npm-audit job in .github/workflows/security.yml to install pnpm, use pnpm install --frozen-lockfile, and run pnpm audit.

Example:

npm-audit:
  name: pnpm audit
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - uses: actions/setup-node@v4
      with:
        node-version: 20

    - uses: pnpm/action-setup@v4
      with:
        version: 9

    - name: Install dependencies
      run: pnpm install --frozen-lockfile

    - name: Audit dependencies
      run: pnpm audit --audit-level=high

Important caveat

This only works if the repo actually includes pnpm metadata, especially a pnpm-lock.yaml.

Right now, the repo clearly uses workspaces:

{
  "name": "c0mpute-monorepo",
  "version": "0.2.0",
  "private": true,
  "workspaces": [
    "apps/*",
    "packages/*"
  ]
}

But the failure only proves npm cannot handle the current install path for this repo in CI. To safely force pnpm, the repo should also have:

• pnpm-lock.yaml
• ideally "packageManager": "pnpm@<version>" in root package.json

Example:

{
  "name": "c0mpute-monorepo",
  "version": "0.2.0",
  "private": true,
  "packageManager": "pnpm@9.12.0",
  "workspaces": [
    "apps/*",
    "packages/*"
  ]
}

If there is no pnpm-lock.yaml

Then don’t force pnpm in CI yet. Instead:

1. migrate the repo locally to pnpm,
2. commit pnpm-lock.yaml,
3. optionally add packageManager,
4. then update the workflow.

Best answer

Yes, you can force it to use pnpm, and that is preferable for a workspace monorepo. The concrete fix is to replace the current npm install/audit step with pnpm/action-setup, pnpm install --frozen-lockfile, and pnpm audit.
If you want, I can also draft the exact patch for PR #3.

Originally posted by @ralyodio in #3 (comment)