[Node.js] NPM Demystified Part-2 : Semantic Versioning Explained.


Let's check our current package.json
  
  "dependencies": {
    "lodash": "^4.17.4"
  }

Semantic Versioning:

In the dependencies, you can find lodash followed by version number. All the node modules follow semantic versioning.

Given a version number MAJOR.MINOR.PATCH and in our lodash example 4 is the major version, 17 is the minor version and 4 is the patch version. We should update the:
  • MAJOR version when incompatible API changes made in our module.
  • MINOR version when we add functionality with backwards-compatible.
  • PATCH version when you make minor bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

We also need to follow semantic versioning system for our node application. 

☝☝Question: Now I'm ok with the version number, Why ^ symbol used before the version number?

Before Major version, you can able to find ^ symbol.  You can use ~, ^ or * with the version details.

  • Patch releases: 1.0 or 1.0.x or ~1.0.4
  • Minor releases: 1 or 1.x or ^1.0.4
  • Major releases: * or x



Let me explain little deeper. Usually, when we push our code to the repository (Git, svn, cvs or Mercurial) we should ignore the node_modules directory because when we add multiple node modules repo will consume huge volume. So User who checks out the code will do npm install and it will install all the modules mentioned in the dependencies of package.json.

Here comes the problem, npm doesn't know which version to install and using ~, ^ and * we can make sure npm install's right version of packages for us. when ~ is used it will install the latest patch version, when ^ is used it will install latest minor version and when * is used npm will install the latest version of the package. We can use ~ and ^ in our package.json because * doesn't have backward compatibility so it will break the existing code and logic. 

These symbols should be managed correctly to avoid versioning problem with the developers and it explains the importance of --save during installation.

OOPS!! Long answer for a small question!!

☝☝Question: shall I modify the version details directly in package.json?

Yes, you can directly modify or add dependency in the package.json but make sure added dependency and version available.

☝☝Question: Finally, how we should include external modules in our code?

var _ = require("lodash");

There is no special method to include external modules, it is same as node internal modules. I have used _ as the variable name since lodash is usually initialized with underscore however you can use any other variable name for lodash and it holds good for any other package.

☝☝Question: Is it fine to start a variable name with _?

Yes, Variable names can contain letter, digits, underscores and dollars sign. It must begin with letters, underscore or dollar sign. Javascript keywords cannot be used as variable name.


our index.js after addition of lodash module.

const http = require('http');
var _ = require('lodash');

const hostname = 'localhost';
const port = 3000;

const server = http.createServer((req, res) => {
 res.end('Hello World\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

In this blog, we have discussed semantic versioning and addition of external node modules into our application. Let's discuss more coding in next blog NPM Demystified Part-3.


If you enjoyed this article, please share with your developer friends. Thanks for reading.

Comments

  1. What would be the default symbol in the version?

    ReplyDelete
    Replies
    1. When you do --save ^ symbol would be default symbol But you can change version symbol in your package.json based on your need.

      Delete
  2. I would like to read more about how you would approach updating dependencies for an application whose packages are all severely outdated. What's the most logical way to start? One by one with the least risky (for breaking changes) package?

    ReplyDelete
    Replies
    1. Yes, It is good to start with least risky package. First try to create a mockup application with the updated package and check how it works, then integrate it with your application.

      Your application might have some outdated packages(no updates/development for the package in the recent years or discontinued package), for those packages you need to find good alternative and use it.

      Delete
    2. try "npm outdated" command you can get list of package details.

      Delete

Post a Comment