On today’s episode of JavaScript Jabber, Charles Max Wood and panelist Joe Eames chat with Rebecca Turner, tech lead for NPM, a popular Javascript package manager with the worlds largest software registry. Learn about the newly released NPM 5 including a few of the updated features. Stay tuned!

[1:58] Was the release of node JS 8 tied to NPM5?


Features in NPM5 have been in planning for 2 years now.
Planned on getting it out earlier this year.
Node 8 was coming out and got pushed out a month.
Putting NPM5 into Node 8 became doable.
Pushed really hard to get NPM5 into Node 8 so that users would get NPM5 and updates to NPM5.


[2:58] Why would it matter? NPM doesn’t care right?


Right you can use NPM5 with any version of node.
Most people don’t update NPM, but upgrade Node.
So releasing them together allowed for when people updated Node they would get NPM 5.


[3:29] How does the upgrade process work if you’re using NVM or some node version manager?


Depends. Different approaches for each
NVM gets a fresh copy of Node with new globals. NVM5 and Node 8 are bundled.
For some, If you manually upgrade NVM you’ll always have to manually. It will keep the one you manually upgraded to.


[4:16] Why NPM 5?


It’s night and day faster.
3 to 5 times speed up is not uncommon.
Most package managers are slow.
NPM 5 is still growing. Will get even faster.


[5:18] How did you make it faster?


The NPM’s cache is old. It’s very slow. Appalling slow.
Rewrote cache
Saw huge performance gains


[5:49] What is the function of the cache?


Cache makes it so you don’t have to reinstall modules from the internet.
It has registry information too.
It will now obey http headers for timing out cache.


[6:50] Other things that made it faster?


Had a log file for a long time. It was called shrinkwrap.
NPM 5 makes it default.
Renamed it to packagelog.json
Exactly like shrinkwrap package file seen before
In combo with cache, it makes it really fast.
Stores information about what the tree should look like and it’s general structure.
It doesn’t have to go back and learn versions of packages.


[7:50] Can you turn the default Packagelog.json off?


Yes. Just:
Set packagelog=false in the npmrc


[8:01] Why make it default? Why wasn’t it default before?


It Didn’t have it before. Shrinkwrap was added as a separate project enfolded in NPM and wasn’t core to the design of NPM.
Most people would now benefit from it. Not many scenarios where you wouldn’t want one.
Teams not using the same tools causes headaches and issues.


[9:38] Where does not having a lock show up as a problem?


It records the versions of the packages installed and where NPM put them so that when you clone a project down you will have exactly the same versions across machines.
Collaborators have the exact same version.
Protects from issues after people introduce changes and patch releases.
NPM being faster is just a bonus.
Store the sha512 of the package that was installed in the glock file so that we can verify it when you install. It’s Bit for bit what you had previously.


[11:12] Could you solve that by setting the package version as the same version as the .Json file?


No. That will lock down the versions of the modules that you install personally, not the dependancies, or transitive dependancies.
Package log allows you to look into the head of the installer. This is what the install looks like.


[12:16] Defaulting the log file speed things up? How?


It doesn’t have to figure out dependences or the tree which makes it faster.
Shrinkwrap command is still there, it renames it to shrinkwrap but shrinkwrap cannot be published.
For application level things or big libraries, using shrinkwrap to lock down versions is popular.


[13:42] You’ve Adopted specifications in a ROC process. When did you guys do that?


Did it in January
Have been using them internally for years. Inviting people into the process.
Specifications
Written in the form of “Here is the problem and here are the solution