Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Your production API is currently running a Node.js major version that is in the "Maintenance LTS" phase. What is the primary operational risk of leaving it there indefinitely?
💻 Code Challenge | +75 XP
Add an .nvmrc pinning Node 20.11.0 and an engines field to package.json that fails npm install on any other major version, then wire an engine-strict check into a CI step.
A teammate's local machine runs a different Node major than the CI pipeline, causing "works on my machine" bugs. Reorder these steps to permanently fix the drift.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant

Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Deploying to production on an odd-numbered Node major (e.g. 21, 23) expecting long-term support
// Wrong: v21 never becomes LTS, EOL in ~9 months
// engines: { "node": ">=21" }
// Correct: v20 is Active LTS with a 30-month lifecycle
// engines: { "node": ">=20 <21" }The Solution //
Odd-numbered majors are Current-only releases — they never enter the LTS track and reach End-of-Life just months after release, with no Maintenance phase safety net. Production workloads should always target the current Active LTS (an even-numbered major), reserving odd releases for previewing upcoming features in non-critical environments.
The Error //
Setting engines in package.json but never enforcing it in CI or locally
# .npmrc — makes engines actually binding
engine-strict=trueThe Solution //
An unenforced engines field is documentation, not a guarantee — npm only prints a warning by default and continues installing anyway, so a developer on the wrong Node version can still push code that breaks in production. Add engine-strict=true to .npmrc (or an explicit CI version check) so a mismatch fails the build instead of silently shipping.