When starting out with Node.js development, one of the first questions that arises is the difference between installing packages locally or globally. At first glance it seems like a minor detail, but choosing incorrectly can lead to difficult-to-debug errors, especially when working in teams or deploying applications to production. At Q2BSTUDIO, as a company specialized in custom software development, we know that proper dependency management is the foundation of sustainable and scalable projects.
Node Package Manager (npm) is the default package manager for Node.js. Its main function is to install, update, and manage the libraries that our code needs. However, npm can place those packages in two different locations: inside the project directory (local installation) or in a system-wide folder (global installation). Understanding when to use each is key to avoiding the classic 'Cannot find module' error.
Local installation: the default and safest option
Running npm install express inside your project folder downloads the package into node_modules/ and records it in package.json under dependencies. This means anyone who clones the repository only needs to run npm install to get exactly the same versions. This practice is mandatory for all libraries that your application uses at runtime, whether a web framework, a database client, or a validation library.
Imagine you develop a REST API with Express and push it to a repository. If another developer clones the project and Express is globally installed on your machine, their terminal will return an error because it cannot find the module. This problem worsens in continuous integration environments or cloud deployments, where the system does not have access to your global packages. That is why at Q2BSTUDIO we always recommend installing locally any dependency that the code needs to run, including those related to cloud infrastructure AWS/Azure that you use from the backend.
Global installation: only for command-line tools
When we use npm install -g nodemon, the package is installed in a system location (e.g., /usr/local/lib/node_modules on Linux or %AppData%/npm on Windows). This allows you to run the nodemon command from any terminal, regardless of the project you are working on. Global packages are useful for tools we use during development, such as typescript, eslint, pm2, or create-react-app. They should not be libraries that your application imports with require() or import.
A common mistake is to install a package like Express or Axios globally, thinking it will then be available in all projects. This works on your local machine, but it breaks project reproducibility. In professional environments, where integration with cybersecurity and BI/Power BI systems requires consistency, we cannot afford hidden dependencies.
What about npx?
Since npm version 5.2, we have npx, a package runner that allows you to execute commands without needing a global installation. For example, npx create-react-app my-app temporarily downloads the package and runs it, without leaving it installed permanently. This is ideal for tools that we use sporadically, such as project generators or specific versions of a CLI. At Q2BSTUDIO we use this strategy to keep development environments clean, especially when working with AI agents or artificial intelligence solutions that require specific library versions.
Practical decision: local, global, or npx?
The rule we apply in our projects is simple: ask yourself who needs the package. If the application needs it (because your code imports it), install it locally. If you as a developer need it to run commands across multiple projects, install it globally. And if you are only going to use it once or occasionally, use npx.
In the context of custom software, this distinction becomes even more relevant. When we build personalized software for clients, dependency management must be documented and replicable. A well-configured package.json prevents surprises in staging and production environments. Additionally, when integrating cloud services like AWS or Azure, connectivity libraries (e.g., aws-sdk) should always be local.
Conclusion
Mastering the difference between local and global packages is not just a technical matter, but one of organization and best practices. It will save you hours of debugging and facilitate teamwork. At Q2BSTUDIO, every project we develop follows these principles, combining a solid dependency foundation with the intelligent use of global tools and npx. If you are starting with Node.js, remember: install locally what your code needs, globally what your terminal needs, and use npx for the rest.
