npm

Created: 2017-02-02 09:30:32 -0800 Modified: 2023-12-06 09:38:58 -0800

Unpublishing and force-publishing

§Section titled Unpublishing and force-publishing

You should never do either of these unless there’s some incredibly compelling reason like pushing a security flaw. The biggest reason why you shouldn’t do this is because you will change the history of your modules. For example:

1. You start your project and you’re using version 1.0.0 of a module.
2. You update the module to be version 1.0.1, 1.0.2, etc.
3. You want to revert to a time when everything should have been pointing at 1.0.1.

If you’d unpublished the module or force-published over it, then it’s possible that reverting wouldn’t actually work. This could mean that rolling back a deploy would cause production to fail or just that you can’t inspect old development builds any longer.

npm audit (reference)

§Section titled npm audit (reference)

This can check for security vulnerabilities and automatically update versions to try to fix them.

I didn’t have package locks when I ran it at first, so it advised that I run “npm i —package-lock-only” first, but that did nothing because “npm config get package-lock” showed “false”, so first I needed to “npm config set package-lock true” and then run it. I also needed to be pointing to the official registry: “npm config set registry https://registry.npmjs.org/“

npm link (npm docs, blog post)

§Section titled npm link (npm docs, blog post)

To get around having to publish a module just so that a local consumer can test out the changes, use “npm link”.

botland-infratest is not in the same repository as the code it’s testing, so I needed to use npm link to work around having to publish every time I want to test something.

Here’s what I did to get that working:

1. cd /d D:CodeBotLandmatchmaker
2. npm link
3. cd /d D:CodeBotLandinfratest
4. npm link @botland/matchmaker

That’s it! If you want to test it, make changes to the module that you linked and make sure the user of the linked module gets the update.

Note that if you ever want to install an older version of a linked dependency, you won’t be able to (since it’s symlinked, not pulling from the npm repository):

> npm install —save @botland/intro.js@2.5.0-adam.6

npm WARN update-linked node_modules\botlandintro.js needs updating to 2.5.0-adam.6 from 2.5.0-adam.9 but we can’t, as it’s a symlink

If you are working with Yarn and you still see it trying to access the public registry even after linking, then perhaps you should follow this issue (you just put “link:RELATIVE _PATH” as the dependency in your package.json file).

Just note that by doing so, the relative path will have to be the same on every machine where you try running “yarn”. As a compromise between “yarn link” and this solution, you can set your relative path to be the symlinked path within node_modules, e.g. link:../node_modules/@botland/foo.

Just a few more notes on “npm link” and “yarn link” (in case there weren’t enough already!)… these are from HiDeoo:

Hey, watched a tiny portion of today’s VOD while cooking and wanted to quickly share some thoughts as I think you may be confused on the use of npm link (and your notes too I think). Feel free to ignore tho ^^

• Avoid using yarn link if you’re using npm as package manager, and vice versa for npm link if you’re using yarn (specially with hoisting involved with yarn workspaces).

• npm|yarn link is a 2 steps development tool mostly dedicated to testing/debugging packages. Packages available through link have symlinks pointing to them in your .config/yarn/link folder, and that’s it. Local projects using linked packages just have symlinks in their node_modules folder pointing to symlinks from .config/yarn/link and nothing more, this means, your package manager don’t really know what’s currently linked & used on your system (aka. yarn link package just create a symlink & nothing more). This means, that when you use a command like yarn to install deps, the package manager don’t know if you previously linked something or not, it doesn’t care. The only sources of truth when installing packages is your yarn/npm global config, your package.json and your lockfile. This means, that 99% of the time, with a basic package.json, it’ll always hit the registry, and that is expected. Aka, if you want a package to always resolve to a local folder, you have to make that permanent through your package.json. A package link is an ephemeral local thingy.

Unlinking

§Section titled Unlinking

If you ever want to unlink (so that you’re not using the local version any longer), read through this

1:58 HiDeoo: Adam13531 I had to come back, for your notes, when linking the first time, it creates a global package pointing to the source. To unlink, you can do it from the destination which will only remove the link but leave the global package, to also remove the global package, you need to unlink from the source https://bpaste.net/show/d8a3caa0852f

Checking existing links

§Section titled Checking existing links

Global:

npm ls -g —depth=0

Local:

npm ls —depth=0

If something is linked, you’ll see a filesystem location instead of nothing:

+— @botland/matchmakerplayer@1.0.0 -> D:CodeBotLandbotlandpackagesmatchmakerplayer

+— bluebird@3.3.5

(matchmakerplayer is linked above, bluebird is not)

Another way to check is to just go into node_modules and see if you find a folder or just a symlink.

save-exact / versioning

§Section titled save-exact / versioning

By default, I believe “save-exact” is set to false, which means that when you do something like “npm install —save lodash”, you’ll see this in your package.json:

“lodash”: “^4.17.4”

The caret means to upgrade minor or patch versions automatically on an “npm update”. The caret is just one of the semver range operators.

If you want to change this option, you can do “npm config set save-exact true” (which may just do it for the current project; consider looking up a global command if that’s the case). Then, when you install a package, you won’t see any range operator:

“lodash”: “4.17.4”

This means to ONLY use 4.17.4 and never update it unless explicitly stated by something like “npm install —save lodash@4.17.5”.

The reason why you may want this is because upgrading can sometimes break your code, so this lets you control the exact version.

UPDATE (4/7/2018): one of the reasons why you don’t want an asterisk/star, as in

”mymodule”: ”*“

…is because if you ever want to revert to an old point in the codebase, you won’t know which dependencies existed at the time, so it’ll try installing the newest versions of everything (which may not be compatible with that version of the codebase).

shrinkwrap

§Section titled shrinkwrap

Shrinkwrapping (or “yarn locks” if you’re using Yarn instead of NPM) can prevent all packages from updating their dependencies.

9:38 EveryJuan: IE if you depend on pixie, and they say left-pad: ^0.1.0, then left pad breaks something, you have an issue

9:39 HiDeoo: Adam13531, There is no guarantee when npm install that you’ll get the same code that you got one hour ago on another server

9:39 HiDeoo: That’s where shrinkwrap comes into plays