My routine npm update, triggered by a GitHub security advisory, runs into the cryptic “Exit handler never called!” error. Alongside a refresher on what package-lock.json and npm update do, my fix is to confirm the lock file is at fault using npm install –no-package-lock, then delete it and regenerate it with a fresh npm install, followed by retesting and rebuilding any artifacts...
I walk through publishing my own JavaScript utility to npm so it can be installed and updated like any other package, rather than copying source files between Node projects. I cover creating an npm account, scoping the package name to my username, writing and publishing the code with npm publish, and installing it in another project, using a simple is-even example...
I add authentication to an old Node.js app by cloning a four-year-old tutorial repo, which produces a flood of npm install errors. I explain how package.json and package-lock.json pin dependency versions (carets, tildes, exact pins, transitive dependencies), then work through escalating fixes in order of risk: deleting the lockfile, loosening version ranges, wildcard updates, and npm audit fix –force, followed by testing...
I deploy a small Node.js and Express service from my MacBook to an Ubuntu VPS, covering the choice between a native install and a Docker container, installing Node and npm via apt (including why the Ubuntu repository version is quite old), and copying project files to the server with scp rather than setting up git-based CI/CD for such a tiny project. I test with Insomnia instead of Postman, which I avoid because of its data collection...
While trying to clear an npm audit vulnerability in my React app’s nth-check dependency, I investigate confusing version mismatches between package-lock.json and npm list, and find that hand-editing the lock file doesn’t survive an install. A GitHub issue on create-react-app explains the flag is effectively a false positive for a dev-only dependency and can be safely ignored, with a workaround for CI builds. My takeaways include a clearer understanding of package.json versus package-lock.json and the value of searching for the exact error first...
