Support pnpm 11

[Maxime-J]

pnpm 11 being tagged as latest version, this introduced errors on install and broken Docker build.

In this PR:
-Migration to the allowBuilds setting, following the default strict policy (all packages needs to be reviewed, error otherwise)
(I followed the previous behavior, but you might want to allow other packages.)

- In Dockerfile deps stage, disable the strict policy so that nothing is built (like before), without error.

- In Dockerfile runner stage:

• Because we're in an hybrid setup (node_modules from script dependencies + the ones from the standalone next.js output) verifyDepsBeforeRun: false is now needed to prevent pnpm from running install on pnpm run.
• --allow-build flag on pnpm add replaced with allowBuilds on that new workspace file.
• pnpm won't run needed postinstall (prisma engine download) if there's a workspace file and no package.json. So an empty package.json is added (which will be replaced afterwards).

[vercel]

@Maxime-J is attempting to deploy a commit to the Umami Software Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR updates the pnpm workspace configuration and Dockerfile to be compatible with pnpm 11, which changed the default build-script policy to strict mode and deprecated onlyBuiltDependencies/ignoredBuiltDependencies in favour of the new allowBuilds map.

• pnpm-workspace.yaml: replaces onlyBuiltDependencies/ignoredBuiltDependencies with an explicit allowBuilds map; @parcel/watcher, @swc/core, esbuild, msw, and sharp are blocked (false), while @prisma/engines and prisma are allowed (true). @prisma/client, which was in the old onlyBuiltDependencies list, is not present in the new map.
• Dockerfile deps stage: injects an inline pnpm-workspace.yaml containing only strictDepBuilds: false so that the frozen-lockfile install can proceed without errors under the new strict policy.
• Dockerfile runner stage: injects an inline pnpm-workspace.yaml with allowBuilds (allowing only @prisma/engines) and verifyDepsBeforeRun: false; adds an empty package.json so pnpm triggers the Prisma engine postinstall during pnpm add.

Confidence Score: 4/5

The Docker build changes are self-contained and follow the documented pnpm 11 migration path; the main open question is whether @prisma/client 7.x has an active postinstall that needs to be listed in allowBuilds.

The Dockerfile changes are well-structured and the strictDepBuilds: false / verifyDepsBeforeRun: false workarounds are sound. The one outstanding question — whether @prisma/client 7.x ships lifecycle scripts that require an entry in allowBuilds — could silently block local developer installs if it turns out the package still has a postinstall. Everything else in the migration looks correct and consistent with pnpm 11 documentation.

pnpm-workspace.yaml — verify that @prisma/client does not require an allowBuilds entry with Prisma 7

Important Files Changed

Filename	Overview
pnpm-workspace.yaml	Migrates from deprecated onlyBuiltDependencies/ignoredBuiltDependencies to allowBuilds map; @prisma/client was previously in onlyBuiltDependencies but is absent from allowBuilds, which may silently break installs if Prisma 7's @prisma/client still ships lifecycle scripts
Dockerfile	Adds inline pnpm-workspace.yaml to both the deps and runner stages; deps stage uses strictDepBuilds: false to silence the new strict-mode errors; runner stage adds an empty package.json workaround so pnpm's postinstall (Prisma engine download) fires correctly

_{Reviews (1): Last reviewed commit: "Support pnpm 11" | Re-trigger Greptile}

[Maxime-J]

See resolved conversations above for Greptile's question on its confidence score.