HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Untitled Lesson

⚡ Total XP: 0|💻 backend XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Committing package-lock.json to be ignored or regenerated inconsistently across a team

// Wrong: .gitignore excludes the lockfile
node_modules/
package-lock.json

// Correct: only ignore node_modules, commit the lockfile
node_modules/

The Solution //

package.json only records loose version ranges (e.g. ^4.18.0), so without package-lock.json committed to Git, different developers (and your CI/production server) can silently install different exact sub-dependency versions, causing 'works on my machine' bugs. Always commit package-lock.json and use `npm ci` (not `npm install`) in CI/production, since npm ci installs the exact locked versions and fails if the lockfile is out of sync.

The Error //

Installing a build/test-only tool as a regular dependency instead of a devDependency

// Wrong: testing tool ends up in production dependencies
npm install jest

// Correct: -D flags it as a dev-only dependency
npm install -D jest

The Solution //

Running `npm install jest` (without -D) adds it to "dependencies" instead of "devDependencies". When a production deploy runs `npm install --omit=dev`, tools correctly flagged as dev dependencies are skipped, keeping the image small — but a testing/linting tool mistakenly listed under dependencies gets installed in production anyway, bloating the deployment and increasing attack surface.