šŸš€ LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.
šŸŽ“ COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.
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

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Committing node_modules but forgetting to commit package-lock.json

# .gitignore should exclude node_modules but NEVER package-lock.json node_modules # package-lock.json must be committed, not ignored

The Solution //

package-lock.json is the artifact that actually guarantees reproducible installs — it pins the exact resolved version and integrity hash of every dependency and sub-dependency. Without it committed to version control, two developers running npm install with the same package.json's caret ranges can end up with different transitive dependency versions, causing 'works on my machine' bugs.

The Error //

Manually editing dependency versions in package.json without regenerating the lockfile

# Wrong: edits package.json only, lockfile now out of sync # (manually changing the version string in package.json) # Correct: updates package.json AND package-lock.json together npm install express@4.19.0

The Solution //

Hand-editing a version string in package.json (e.g. bumping "express": "^4.18.2" to "^4.19.0") doesn't update package-lock.json automatically in every workflow, and running npm ci afterward will fail or install the old locked version instead of what you intended. Use npm install <package>@<version> instead of hand-editing, so npm updates both files together.

Continue Learning