Repository navigation
Conversation
Fixes stale commands and facts, adds how to run a single test and the integration suites, explains how the CLI, worker and engine fit together, and drops material that restates package.json or the directory layout.
The typesync script is `_typesync`, and runtime-manager was renamed to engine-multi long ago, so the worker's start:watch was watching a path that no longer exists.
Corepack no longer ships with Node from v25. pnpm reads packageManager and switches itself to the pinned version, so any installed pnpm will do: CI uses the one preinstalled in the cimg/node images, and the worker image installs the pinned version with npm. Refs #1563
| ## Installing | ||
|
|
||
| This repo uses node corepack to ensure pnpm v8 is used | ||
| Install pnpm globally. When run inside this repo, pnpm reads the `packageManager` field in `package.json` and switches itself to the pinned version. |
There was a problem hiding this comment.
Is this true? I can't see any mention of this in pnpm's (increasingly slop heavy) docs
There was a problem hiding this comment.
This is true I think, but devengines.packageManager is I think the most correct way to specify the version. That's implemented on this PR but this doc note is wrong either way. Maybe I'd just remove it and note that package.json locks the version
| RUN corepack enable | ||
| COPY . /app | ||
| WORKDIR /app | ||
| RUN npm install -g "$(node -p "require('./package.json').packageManager.split('+')[0]")" |
There was a problem hiding this comment.
The readme claims that if pnpm is installed globally, it'll load the version in packageManager. In which case we don't need this fancy pantsy expression here?
I'd also prefer this just used npx pnpm-get - but I'm not totally sure how we pin the version. I think devEngines.packageManager might be it
There was a problem hiding this comment.
Just run some tests and npx pnpm-get does not install the the packageManager declared on package.jsson (top level Or on devengines)
There was a problem hiding this comment.
devengines.packageManager works for pnpm install. But you have to do a double install in CI then... install the latest version and then it'll download the correct one. It's super quick on my machine at least and this CI task only runs occasionally - I'm tempted to do it
There was a problem hiding this comment.
Right that was my understanding/learning when I raised that first issue, pnpm installs pnpm. What a time to be alive.
What's that npx flavour of install?
There was a problem hiding this comment.
It's listed on their install docs, along with a bash script. I think they both do the same thing, which is install a fixed version ignoring package json.
But you can bootstrap with one of those and then self-select the correct version in all pnpm commands afterwards by "locking" it in package.json like this. It seems to work.
There was a problem hiding this comment.
I have no idea if we should use npm, npx or bash 🙃 Whatever, no opinion there
declaring the vesion on devengines.packagemanager seems to work better with pnpm. it'll automatically download the correct version, so all users can read pnpm frm the same place No need for asdf (which js dev community won't use) or corepack this way. The docker build has been simplified and should also use the declared pnpm version
Short Description
Some small changes required for OFN-4772.
Stops relying on corepack to install pnpm, since it no longer ships with Node 25+. Also refreshes CLAUDE.md and fixes a few stale references.
Fixes #1563
Implementation Details
pnpm reads the
packageManagerfield and switches itself to the pinned version, so any installed pnpm will do:corepack enablestep. Every job already used the pnpm that comes preinstalled in thecimg/nodeimages, which switches to 12.6.0.corepack enablewith annpm install -gof the exact version inpackageManager.npm install -g pnpm, thenpnpm install.Node versions are unchanged here (still Node 24 for the image and CI). Moving to Node 26 will be a follow-up.
Smaller fixes:
pnpm run typesync, but the script ispnpm _typesync.start:watchwatched../runtime-manager/dist, which no longer exists. It now watches../engine-multi/dist.QA Notes
pnpm -vincimg/node18.20, 22.20, 24.18.1 and 26.5.1 with this repo'spackage.json. All four resolve to pnpm 12.6.0, so the integration matrix and legacy job are fine. I also ran a script through pnpm on Node 18 to make sure it works there.node:24-alpine. pnpm 12.6.0 installs and the build passes. npm warns that it skipped pnpm's own install scripts, but pnpm works without them.AI Usage
Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):
You can read more details in our
Responsible AI Policy