Modern Full-Stack Development

 Updating  Packages
Once you have a project set up, you may on occasion want to update the packages it 
depends on. This is very easy to do:
npm update
Yep, that’s it! NPM will go off and update all packages to the latest version, respecting 
your SemVer settings. You naturally can stick a -g in there too in order to update global 
packages.
 Publishing/Unpublishing  Packages
The final NPM topic I want to touch on is publishing (and optionally unpublishing) 
packages, usually to the central NPM registry (though nothing says you can’t have your 
own private registry to work with).
Publishing to a registry is quite easy! First, you’ll need to, well, write your package! 
Gotta have something to publish, right? You don’t need to do anything special, but npm 
init your project and cobble your code together.
Once that’s done, create an account on the registry’s web site. Next, you’ll need to log 
into that account from the command line:
npm login
This will prompt you for your username, password, and eMail address. Once you’re 
logged in, publishing is a snap:
npm publish
As long as you’re in your package’s root directory (the one you ran npm init in and 
that now has your package.json file), it will be published.
Chapter 2   a Few More words: advanCed node and npM

---

29
Well, hold up, there’s one thing that can go wrong: your package name could already 
be taken. It’s always a good idea to do an npm search for the name first, but assuming 
the name isn’t taken (or you’ve changed it after discovering a collision), then it’ll be 
published and available in the registry immediately.
Tip  If the name you really want isn’t available, npM also lets you publish to a scope. 
this means, for example, you can change the name to @/
name> (or do npm init --scope=). You’ll then also need to add 
--access public to the publish command. that way, as long as your package 
name is unique within the scope, then you’re good to go; the name can be used in 
other scopes without issue (and no scope is effectively the default scope!). so, if, like 
domain names, the one you want is taken, there’s a way around it in npM land.
If you for some reason down the line decide you need to remove your package from 
the registry, it’s as simple as
npm unpublish [<@scope>/]
[@]
If you don’t specify a version, then all versions will be removed.
Two important notes here: First, removing a package is generally considered bad 
form because others may be depending on it. The better thing to do is to use another 
command: deprecate. That will mark your package as deprecated, optionally applying 
a message you can specify about what happens. Second, it’s essential to understand that 
even if you unpublish a package, the name and/or name-plus-version combination can 
never be reused. So again, if you want to be a good citizen, it’s best not to unpublish but 
instead deprecate the package (better still not to publish something you later have to 
remove or deprecate – but it happens, so NPM has you covered in either case with these 
two commands).