This article should serve as an all-in-one essential guide for Node.js’ favorite sidekick: npm.

Node.js has been taking the world by storm since 2009. Hundreds of thousands of systems have been built using Node.js, prompting the developer community to claim that “JavaScript is eating software”.

One of the major factors of Node’s success is npm - its popular package manager, which allows JavaScript developers to share useful packages like lodash and moment quickly and easily.

As of the moment I’m writing this post, npm has facilitated the publication of over 1.3 million packages with a weekly download rate of over 16 billion! These numbers are fantastic for any software tool. So now let’s talk about what exactly npm is.

What is NPM?

NPM – or “Node Package Manager” – is the default package manager for JavaScript’s runtime Node.js.

It’s also known as “Ninja Pumpkin Mutants”, “Nonprofit Pizza Makers”, and a host of other random names that you can explore and probably contribute to over at npm-expansions.

NPM consists of two main parts:

• a CLI (command-line interface) tool for publishing and downloading packages, and
• an online repository that hosts JavaScript packages

For a more visual explanation, we can think of the repository npmjs.com as a fulfillment center that receives packages of goods from sellers (npm package authors) and distributes these goods to buyers (npm package users).

To facilitate this process, the npmjs.com fulfillment center employs an army of hardworking wombats (npm CLI) who will be assigned as personal assistants to each individual npmjs.com customer. So dependencies are delivered to JavaScript developers like this:

and the process of publishing a package for your JS mates would be something like this:

Let’s look at how this army of wombats assist developers who want to use JavaScript packages in their projects. We’ll also see how they help open-source wizards get their cool libraries out into the world.

package.json

Every project in JavaScript – whether it’s Node.js or a browser application – can be scoped as an npm package with its own package information and its package.json job to describe the project.

We can think of package.json as stamped labels on those npm good boxes that our army of Wombats delivers around.

package.json will be generated when npm init is run to initialise a JavaScript/Node.js project, with these basic metadata provided by developers:

• name: the name of your JavaScript library/project
• version: the version of your project. Often times, for application development, this field is often neglected as there’s no apparent need for versioning opensource libraies. But still, it can come handy as a source of the deployment’s version.
• description: the project’s description
• license: the project’s license

npm scripts

package.json also supports a scripts property that can be defined to run command-line tools that are installed in the project’s local context. For example, the scripts portion of an npm project can look something like this:

{
  "scripts": {
    "build": "tsc",
    "format": "prettier --write **/*.ts",
    "format-check": "prettier --check **/*.ts",
    "lint": "eslint src/**/*.ts",
    "pack": "ncc build",
    "test": "jest",
    "all": "npm run build && npm run format && npm run lint && npm run pack && npm test"
  }
}

with eslint, prettier, ncc, jest not necessarily installed as global executables but rather as local to your project inside node_modules/.bin/.

The recent introduction of npx allows us to run these node_modules project-scoped commands just like a globally installed program by prefixing npx ... (i.e. npx prettier --write **/*.ts).

#npm #node #javascript #developer