It's become less popular with the introduction first of ``shrinkwrap`` and then ``package-lock.js``. At one point in time, it was recommended behavior in the official NPM documentation for site deployments, because there wasn't a way to checksum dependencies.
They've since switched to recommending private repositories like Artifactory instead, which to be fair is usually better for very large organizations nowadays. But that wasn't always the case, and even as recent as 2013, it was the flat-out prevailing advice from package managers like Bower, and there are organizations who are still using and maintaining codebases that were set up in 2013.
You won't see a lot of projects on Github that rely on it, because:
A) Usually Open Source projects are designed to be built on multiple environments/OSes.
B) The majority of Open Source Javascript projects are designed to be installed via NPM anyway, and of course you wouldn't include dependencies for something like that.
However, you want to be careful not to make the mistake of assuming that every project has the same concerns as a standard Open Source project. Especially if an Org is going all in on standardizing dev environments through Vagrant or Docker, the question becomes, "why would you want an extra checkout/build step on top of that?"
They've since switched to recommending private repositories like Artifactory instead, which to be fair is usually better for very large organizations nowadays. But that wasn't always the case, and even as recent as 2013, it was the flat-out prevailing advice from package managers like Bower, and there are organizations who are still using and maintaining codebases that were set up in 2013.
You won't see a lot of projects on Github that rely on it, because:
A) Usually Open Source projects are designed to be built on multiple environments/OSes.
B) The majority of Open Source Javascript projects are designed to be installed via NPM anyway, and of course you wouldn't include dependencies for something like that.
However, you want to be careful not to make the mistake of assuming that every project has the same concerns as a standard Open Source project. Especially if an Org is going all in on standardizing dev environments through Vagrant or Docker, the question becomes, "why would you want an extra checkout/build step on top of that?"