Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions .github/workflows/run_tests.yml
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,9 @@ jobs:
- name: Checkout repository
uses: actions/checkout@v4

# Deliberately still 22 while nuxt-app moves to 24: this tree has its own lockfile, its own
# Jest setup, and is frozen pending the Directus licence clarification. Moving its runtime
# would be an untested change to a tree nobody is allowed to upgrade.
- name: Use Node.js 22.x
uses: actions/setup-node@v4
with:
Expand All @@ -43,10 +46,12 @@ jobs:
- name: Checkout repository
uses: actions/checkout@v4

- name: Use Node.js 22.x
# Reads nuxt-app/.nvmrc rather than naming a version here, so CI and local development cannot
# drift apart again — there is one file to change, not three.
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: 22
node-version-file: nuxt-app/.nvmrc

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Update the setup guide to require Node 24 for Nuxt

After this workflow begins sourcing Node 24 from .nvmrc, the root README.md still tells Nuxt contributors that Node 19+ is sufficient and that CI uses v22. A developer following those setup instructions can therefore work and validate on a runtime excluded by the new engines.node range and different from CI; distinguish the Nuxt requirement of Node 24 from the Directus tree's Node 22 requirement.

AGENTS.md reference: AGENTS.md:L21-L22

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, and fixed. README.md:13 said:

These install instructions assume you are using Node.js version 19+ (CI uses v22, tested up to v24).

Wrong on both counts after this PR, and wrong in the file a new contributor reads before any other. It also had a **Prerequisites for Node 22+:** heading below it.

Replaced with a table, because your framing is the important part — the two trees genuinely differ now and the README should say so rather than give one number:

tree Node source of truth
nuxt-app 24 nuxt-app/.nvmrc, which CI reads too. engines.node requires ^24.11.0 || >=26.0.0
directus-cms 22 its workflows; deliberately left behind while the tree is frozen

Plus a line noting Node 24 is also what production runs, since Vercel resolves it from engines.node — which is the fact that made this whole alignment a documentation change rather than a runtime one.

AGENTS.md was already updated in the first commit; the README was the one I missed.

cache: 'npm'
cache-dependency-path: 'nuxt-app/package-lock.json'

Expand Down
4 changes: 2 additions & 2 deletions .github/workflows/smoke_tests.yml
Original file line number Diff line number Diff line change
Expand Up @@ -22,10 +22,10 @@ jobs:
- name: Checkout repository
uses: actions/checkout@v4

- name: Use Node.js 22.x
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: 22
node-version-file: nuxt-app/.nvmrc
cache: 'npm'
cache-dependency-path: 'nuxt-app/package-lock.json'

Expand Down
3 changes: 2 additions & 1 deletion AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,8 @@ A podcast/conference/meetup platform for the German developer community. Built w
- **Server**: Nitro (Nuxt's server engine)
- **Search**: Algolia
- **AI**: Google Gemini (spam filtering)
- **Node**: v19+ (v22 in CI)
- **Node**: 24 for `nuxt-app` — see `nuxt-app/.nvmrc`, which CI reads too. The Directus extension
still builds on 22.

## Directory Structure

Expand Down
12 changes: 10 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,17 @@ Source code of: [https://www.programmier.bar/](https://www.programmier.bar/)

## Setup

These install instructions assume you are using Node.js version 19+ (CI uses v22, tested up to v24).
**The two trees need different Node versions.** Run `nvm use` (or your manager's equivalent) inside the
directory you are working in:

**Prerequisites for Node 22+:**
| tree | Node | source of truth |
| --- | --- | --- |
| `nuxt-app` | **24** | `nuxt-app/.nvmrc`, which CI reads too. `engines.node` requires `^24.11.0 \|\| >=26.0.0` |
| `directus-cms` | 22 | its workflows; deliberately left behind while the tree is frozen |

Node 24 is also what production runs — Vercel resolves it from `nuxt-app/package.json`'s `engines.node`.

**Prerequisites:**
- Python 3 with setuptools (for native module compilation)
- On macOS: `brew install python-setuptools`

Expand Down
175 changes: 166 additions & 9 deletions docs/dependency-upgrade-plan.md

Large diffs are not rendered by default.

2 changes: 0 additions & 2 deletions nuxt-app/.npmrc

This file was deleted.

2 changes: 1 addition & 1 deletion nuxt-app/.nvmrc
Original file line number Diff line number Diff line change
@@ -1 +1 @@
v22
24

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have found a real gap, and I am leaving it open — because the fix it implies is worse than the gap. Explaining rather than just declining.

The gap is real. .nvmrc: 24 permits 24.0.0–24.10.x, which engines: ^24.11.0 forbids. A PR whose whole claim is "every declaration agrees" should not contain two that disagree.

But .nvmrc supports no ranges. There is no value meaning "≥24.11 inside major 24". The options are a major (24), a minor series (24.11 → 24.11.x only), or an exact version. Pinning 24.11.0 would hold both CI and developers on a superseded patch with no Node security releases inside the major — CI resolved 24.18.0 today and would install 24.11.0 instead. That trades a narrow, unlikely problem for a permanent one.

What actually happens: both resolvers select the newest available 24.x, so .nvmrc: 24 satisfies engines in every normal case — verified in this PR's own CI run, which picked v24.18.0 from the file. The residual risk is a developer who already has an old 24.x installed: nvm use would select it, and npm then only warns (EBADENGINE).

The only way to close it properly is engine-strict=true, which promotes that warning to a hard install failure and makes the floor genuinely binding. I have not added it here: it changes install behaviour for other people — a wrong local Node would fail npm install rather than warn — and that is outside a PR whose claim is that install behaviour is unchanged. It is one line in a new nuxt-app/.npmrc if the maintainer wants it, and it would be an .npmrc containing an option that actually does something, unlike the one this PR deletes.

Both the gap and that option are now written down in docs/dependency-upgrade-plan.md rather than left implicit.

2 changes: 1 addition & 1 deletion nuxt-app/package-lock.json

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion nuxt-app/package.json
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
"version": "0.0.0",
"private": true,
"engines": {
"node": "^22.19.0 || ^24.11.0 || >=26.0.0"
"node": "^24.11.0 || >=26.0.0"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Regenerate the lockfile's root engine metadata

The corresponding root package entry in nuxt-app/package-lock.json still contains ^22.19.0 || ^24.11.0 || >=26.0.0. As a result, tools reading the committed lockfile still see Node 22 as supported, and the next npm install rewrites the lockfile solely to synchronize this field. Regenerate and commit the lockfile alongside the package.json change so the repository consistently declares Node 24.

AGENTS.md reference: AGENTS.md:L21-L22

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same finding as the Copilot comment above, and correct — synced.

One detail worth adding for anyone reading this thread later: your prediction that "the next npm install rewrites the lockfile solely to synchronize this field" holds under npm 10, but not under npm 11. Under npm 11 — the npm that ships with Node 24, which this PR puts in CI — the same command rewrites 168 lines, stripping "dev": true from ~50 optional packages.

npm 10 (Node 22):  1 insertion(+), 1 deletion(-)
npm 11 (Node 24):  13 insertions(+), 155 deletions(-)

So I generated the sync under npm 10 to keep this PR to the field in question. The reclassification is not cosmetic — npm ci --omit=dev would install a different set afterwards — and it is logged as its own backlog item with a note to verify a production-shaped install before and after, rather than trusting it.

},
Comment on lines 5 to 7

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, and fixed — but syncing it turned out to be more interesting than a one-line change, so worth recording how.

npm install --package-lock-only under npm 11 (the npm that ships with Node 24, i.e. what this PR puts in CI) rewrites 168 lines: it strips "dev": true from roughly fifty optional packages (@emnapi/* and similar). The same command under npm 10 changes exactly one line — the engines field you identified.

npm 10 (Node 22):  1 file changed, 1 insertion(+), 1 deletion(-)
npm 11 (Node 24):  1 file changed, 13 insertions(+), 155 deletions(-)

So that churn is npm 11's changed dev/optional classification, not a consequence of narrowing engines. I generated the sync under npm 10 to keep this PR to the field in question, because the reclassification has semantic content — npm ci --omit=dev would install a different set afterwards — and this PR's claim is that nothing about the runtime or install behaviour changes. Bundling fifty unverified reclassifications in would have made that claim false.

Logged as its own backlog item, with the note that it is already live and harmless: Vercel builds on Node 24, so production has been resolving this lockfile with npm 11 for a while without trouble.

"scripts": {
"build": "nuxt build",
Expand Down
Loading