Which tool does your project need to install, run or build?
Start with the instructions in your project. A package manager installs the code your app depends on. A runtime runs your code. A build tool prepares files the app or browser can use. One project can use all three.
What should you open before running an install command?
Read the README and package.json in the project root. A lockfile can be a clue to which manager the project uses. If there are multiple lockfiles, check which one the team and build actually use before changing any files.
Start with the job the project asks you to do. A command that installs packages can prepare a folder of downloaded code. A command that starts a local server can run JavaScript. A build command can call another tool to prepare files. The command name alone does not tell you everything it will do.
Which files matter when someone adds a package?
Review the manifest and the matching lockfile together. The first says what the project asks for. The second records the selections the package manager resolved.
The installed packages normally live in node_modules. That folder is recreated on the next machine. Keep meaningful configuration files under version control, with credentials supplied separately. Before installing, read the relevant scripts and check what dependency you are bringing in.
Compare tools
Scroll the table sideways to read every column.
| Tool | What it doesThe step it handles when you set up, run or ship an app. | What to look forThe file or setting that shows whether your project uses it. | What to matchThe version or configuration your computer and build should agree on. | What to carry forwardThe files and requirements another machine needs to repeat the work. |
|---|---|---|---|---|
| npm | Installs JavaScript packages and runs named project commands. | Look for package-lock.json and npm instructions. | Match the required Node.js and npm versions, install options and registry. | Keep the manifest and lockfile. Use npm ci for a clean install in a trusted project. |
| Node.js | Runs JavaScript on your computer, during a build or in a live service. | Check whether the project or hosting setup names a Node.js version. | Use a project-compatible supported release for the build and any Node.js service. | Keep the version requirement and source. Carry the package manager’s lockfile for dependencies. |
| pnpm | Installs JavaScript packages and can reuse package files across projects. | Look for pnpm-lock.yaml, a manager pin and any pnpm-workspace.yaml. | Match the pnpm version and the app’s Node.js requirement separately. | Keep the manifest, lockfile and workspace configuration. Use a frozen install in CI. |
| Yarn | Installs JavaScript packages and runs project commands. | Check the README, yarn.lock and the Yarn version pin. | Match Classic or Modern Yarn, the Node.js version and the configured dependency layout. | Keep the manifest, lockfile and Yarn settings. Use the lockfile check documented for that release. |
| pip | Installs Python packages into a selected environment. | Check the Python version and the project’s requirements or installation instructions. | Match the Python version, virtual environment and intended package source. | Keep the dependency files and recreate the environment. Check pins and platform before reusing it. |
| uv | Manages Python versions, dependencies and the project environment. | Check pyproject.toml, uv.lock and any .python-version request. | Match the project’s Python and uv versions, the intended package source and the platform. | Keep the project files and lockfile. Recreate the environment and use the project’s documented lock check. |
| nvm | Selects which Node.js version a compatible shell uses. | Check .nvmrc, the README and the build’s Node.js setting. | Match the Node.js release, system and processor. For native Windows setup, check the separate nvm-windows tool. | Keep .nvmrc with the setup instructions and have the build select the intended release. |
| Vite | Builds browser files and previews changes during development. | Look for Vite in the build scripts and the configured output folder. | Match the project’s Vite, template and supported Node.js versions. | Keep source, package lock, build settings and the host’s output path. |
| Docker | Builds an image that packages an app and the runtime it needs. | Look for the Dockerfile and how the host starts a container. | Match the image’s operating system and processor target to the host. | Keep the build recipe and image version. Back up stored records separately. |
| Bun | Installs JavaScript packages and can run the app as a separate choice. | Look for bun.lock and the build and launch commands. | Match Bun and the target platform. Check Node.js compatibility if switching runtimes. | Keep the reviewed lock and build settings. Use a locked install for the recorded versions. |
Can you rehearse an install decision without running project code?
Yes. Draw the files for a fictional project and check how the dependency request, locked version and runtime fit together.
- Pick the managerImagine a README says npm and the project contains package-lock.json. Write npm as the manager and Node.js as the runtime. No terminal command is needed.
- Spot the mismatchImagine package.json now asks for a new major version but the lockfile still names the previous one. Record that the files need a deliberate update before a clean install can use them together.
- Check what the deployment needsWrite down which Node.js version the build uses and whether the deployed app actually runs Node.js. A build can use Node.js even when the finished site serves only prepared files.
How do you keep local and automated builds in sync?
Use the same committed dependency files and project-compatible tool versions on both. CI means the automated job that checks or builds your code. A clean or frozen install can stop when the manifest and lockfile disagree instead of silently choosing new versions.
A lockfile cannot supply a missing private registry credential or make a package work on a different operating system. If you switch package managers, update the install instructions and automation on a separate branch, compare the new lockfile, and check the app before merging.