Command "npm update" vs package "npm-check-updates" - npm-update

What is the difference between the command npm update and the package npm-check-updates? Is it fully safe to use the latter?
It seems after executing npm update not all packages are updated, thus it seem it is incomplete. Many other popular SO answers refer to use first the prior command and then the latter, but I still do not understand what the latter does that the prior does not.

A bit late to the party but I felt like the previously accepted answer is outdated and slightly lacking.
What npm Offers
npm update - updates the dependencies both in package.json and package-lock.json in accordance to the semantic version rules defined in package.json.
Key features of npm update:
It will never update to a breaking version.
(npm#7 and above) You can choose to update only the package.json file with npm update --package-lock false. However, this flag will completely ignore package-lock.json and hence automatic pruning of extraneous modules will also be disabled.
(npm#7 and above) You can see the changes npm update will perform with the flag --dry-run, without actually updating.
npm outdated - shows all the packages that have newer versions available, this includes breaking changes.
It prints a table that includes the package, the current version, the wanted version - according to the semver rules in the package.json - the latest version and the location of the package.
What npm-check-updates Offers
Running ncu without any flags will print a list of all the outdated packages and the version to which it would update, but will not apply any changes.
ncu --update - apply changes to the package.json file only. It will change the versions of all the dependencies in package.json to the latest (even if it's a breaking version!), but will not modify the package-lock.json file. For that, you will need to run npm install.
ncu --target [patch, minor, latest, newest, greatest] - choose which type of version to list/update.
npm vs. ncu
Feature
npm
ncu
Show Outdated Packages
npm outdated - shows wanted & latest versions
ncu - shows latest by default, can be customised
Update Packages
npm update
ncu -u
Breaking Versions
Never updates to a breaking version, but shows them in npm outdated
Updates to and shows breaking version by default, can be customised
package.json SemVer Rules
npm outdated shows the "wanted" version according to SemVer rules, updates to "wanted" version
Disregards SemVer rules (unless explicitly specified), can be customised to update to different types of versions
Files Modified
Modifies package.json and package-lock.json and installs the updated modules
Modifies package.json, doesn't change package-lock.json and doesn't automatically install
Customisation
Can ignore package-lock.json (npm#7) and choose which packages to update
Can choose what kind of version to update to (minor, patch, latest, greatest, newest) and which packages to update

npm-check-updates will only modify your package.json file. Once you've run that command, you'll then need to run a separate npm install to grab those changes. On the other hand, npm update will do all of that, and not give you the chance to check what is being updated beforehand.
There used to be an annoyance that npm update did not update the package.json file but this is no longer the case from 5.0.0. And way back when, it also looked at package dependencies which caused no end of problems for a lot of people.
The key difference between the two is that you can run ncu (the alias for npm-check-updates) and, by default, it will not update your packages - merely tell you what packages need to be updated.
For example, below is the output from one of my legacy projects. Here, you can see that a few grunt packages are out of date, mainly because I no longer work on this project, prefer write build scripts in npm, and haven't had the time to update older projects.
λ ncu
Checking D:\Github\XQSF_Master\web\package.json
[====================] 10/10 100%
grunt ^1.0.3 → ^1.0.4
grunt-contrib-clean ^1.0.0 → ^2.0.0
grunt-contrib-cssmin ^2.2.1 → ^3.0.0
grunt-contrib-uglify ^3.2.1 → ^4.0.1
grunt-sass ~2.0.0 → ~3.0.2
Run ncu -u to upgrade package.json
No changes to my project were made - it simply told me what needed to be updated. This is why I prefer npm-check-updates. By default it doesn't make any changes.
If you DO want changes to be made by ncu, simply run ncu -u. This will update your package.json, but you will still need to run npm install for the node_modules folder to be updated to your new packages.

Well, after some investigation and after a lot of misinformation I think I finally got it.
npm-check-updates will modify your package.json file with the latest updates of each package, and not respecting any npm semantic versioning, meaning that your project may break. Once you've run npm-check-updates, you'll then need to run a separate npm install to grab those changes to the latest versions.
On the other hand npm update updates the packages to its latest versions according to the semantic versioning set in the file package.json.
For example a major release in a dependency (an increase in the first digit in the 3 figures version) makes changes that may break backward compatibility. If you set that dependency in package.json with the caret symbol ^, the command npm install will not make an update of a major release whereas npm-check-updates will. Check this 5 minutes video of npm because it is very clarifying.

Related

Using the most recent version of zarith with opam

I am using zarith for handling arbitrary sized integers.
The most recent version I could find on opam.ocaml.org was v1.9.1 (published in August 2019). On the project's github page I read Latest commit a9a309d on 23 Jan (2020).
I'd like to switch to the newer version, but how do I do that? I want to
keep opam happy, and
always use the most current version of zarith.
Please help!
Indeed, currently 1.9.1 is both the latest version of Zarith available as an opam package (https://opam.ocaml.org/packages/zarith/) and as a GitHub tag (https://github.com/ocaml/Zarith/tags).
However, given this upstream Git repository also contains an .opam specification file, you can just as well use opam to install the latest development version available in the master branch, or if need be, a precise Git commit just by relying on the so-called pinning feature of opam.
So, you can run alternatively:
opam pin add -n -y -k git zarith.dev --dev-repo
or
opam pin add -n -y -k git zarith.dev "https://github.com/ocaml/Zarith.git#master"
or
opam pin add -n -y -k git zarith.dev "https://github.com/ocaml/Zarith.git#a9a309d0596d93b6c0c902951e1cae13d661bebd"
Then:
opam install zarith
Further details on the opam-pin command
The .dev version suffix is unneeded syntactically, but is recommended actually, as the zarith.opam file does not specify any version. To be more precise:
If you have other dependencies that would complain of zarith.dev when being installed, you can replace the version suffix of dev with any compatible version string, "close" to the commit or branch you selected.
However if you omit this version, opam will typically pick the latest version string from the opam package repository (i.e., 1.9.1), which wouldn't necessarily match the code of the Git branch or commit you selected.
-n, -y, and -k are the short form of the options:
--no-action (don't install the package readily but wait the subsequent opam install command),
--yes (answer potential yes/no questions without prompting − a common opam pin question is Package foo does not exist, create as a NEW package? [Y/n] if ever you'd want to install a custom package not yet released in the opam-repository),
--kind=KIND (as there are several KINDS of pinning, the most typical being version, path, and git)
If you really need to use the unreleased, in-development version of zarith you can use the --dev-repo option of opam pin add:
opam pin add --dev-repo zarith
opam install zarith

Automatically redirect PPA to new package name

I maintain the PPA for Bookworm here:
https://launchpad.net/bookworm
Recently I have changed the package name from "bookworm" to "com.github.babluboy.bookworm" based on the RDNN requirements of Elementary OS AppStore
This requires that the installation on Ubuntu is done by the command "sudo apt-get install com.github.babluboy.bookworm" instead of "sudo apt-get install bookworm".
While I have signposted this on Launchpad and the Bookworm website, there are a lots of posts and blogs on the internet from earlier asking users to use the "sudo apt-get install bookworm" command. This will install an old package (still in the PPA) which I don't update anymore.
Is there a way I can set up in Launchpad so that the older package automatically points to the new one for installation.
A hack that I can think of is to update the old package so that there is a big banner on the app providing instructions to switch to the new package. But thought of asking here if there is a more elegant way to manage package name changes in PPA
What you need is a transitional package with the old name. This will be an empty package with no actual contents, which has the new package as a dependency. When people update/install the bookworm package, it will be installed, and will pull the new package as a dependency. A future version of the new package can declare the old one as a conflict, and remove it while updating.
Debian Wiki has the information you need in much more detail. For a number of package transition scenarios, see this:
https://wiki.debian.org/PackageTransition
Case #5 : Rename is what you need from there. The exact page you want is this
https://wiki.debian.org/RenamingPackages
There are other methods explained on that page, like the 'Clean Slate Method', but the 'Transition package method' is the one which is much more cleaner, and recommended. (If you search apt for 'transitional package', you'll find a lot of them).

How to upgrade a single package?

I did opam update and then opam upgrade, and now OPAM wants to upgrade 10 packages to more recent versions.
However, for fear of breaking something inadvertently, I'd like to upgrade a single package, without touching the others. This package has no dependencies and it seems that none of the other packages depends on it.
However, doing opam upgrade <package> results in the same thing as opam upgrade, that is, OPAM wants to upgrade all 10 packages, not just the one I want.
I even tried opam install <package>.<new version>, but it also wants to upgrade everything at once.
Is there a way to upgrade just this single package, without touching the rest? In theory nothing should break, but in practice it often happens...
I found out that doing
opam reinstall <package>.<new version>
allows me to obtain what I want, that is, install only package <package> and its dependencies, without upgrading unrelated packages.
OPAM emits a warning ([WARNING] <package>.<new version> is not installed.), but it proposes me to install it anyway.
Afterwards, despite some warnings about the destination directory not being empty (due to the already installed previous version), OPAM was able to install only the desired package, without upgrading everything.
Notice that the same thing happens if I try to install a new package: because my previous opam update added several packages to the update list, trying to install anything via opam install will trigger the "update everything" algorithm, while opam reinstall won't.
I don't know if this is undesired behavior, but if so, I hope that it will remain available in future OPAM versions, or that there will be a way to ignore unrelated upgrades.
Edit: as indicated in this OPAM Github issue, using --criteria=paranoid or --criteria=-changed,-notuptodate can also help with not modifying anything else.

Opam not getting latest packages

I just installed opam using the quick install
http://opam.ocaml.org/doc/Quick_Install.html
I now have
$opam --version
1.1.0
which is current. I ran "opam update" and "opam upgrade" to get the latest packages. However, when I install packages, it is still giving me the old versions (such as core 109.42 instead of core 109.55):
$ opam search core
Available packages for 4.01.0:
async_core 109.42.00 Monadic concurrency library
What do I need to do to get opam to give me the latest libraries?
If you previously built from source, make sure you uninstall that first. For whatever reason, even though the opam version correctly reports "1.1.0", it was still using the old repo address. After you uninstall old opam entirely, then follow the installation instructions at the link above.
You will know you succeeded when you do "opam update" and prints:
default Downloading http://opam.ocamlpro.com/urls.txt
[NOTE] The repository 'default' will be *permanently* redirected to https://opam.ocaml.org (opam-version >= "1.1.0")

How do I use a virtualenv-based deployment method without upgrading to each and every upstream version?

Last Friday, I've built an RPM spec for my Django project. The RPM creates a virtualenv, downloads dependencies via pip and puts everything into the packages. Today, I've found out that BeautifulSoup 3.2 has been released. Luckily, I've had my BeautifulSoup version pinned in the requirements.txt, so I found out because of the build failing.
Now a completely different matter is: how do I do avoid upgrading stuff in the future? BeautifulSoup has deleted all previous versions from PyPI, so I can't download a version I've actually tested against. pip's download cache doesn't help here either, since pip always tries to check PyPI first.
Can you recommend something to avoid this situation?
First, this is an unusual situation. I've never seen another package remove all old releases the way BeautifulSoup does. I consider that rather user-hostile behavior, except perhaps in cases of a serious security fix.
That said, if you want a reliable build process using pip, you really need to mirror all the packages you rely on locally. It's not hard to do; you can use pip's --download option (or your existing pip cache) to get all the package tarballs, then just dump them in an indexed, web-served directory and use --find-links in your requirements file to point pip there (plus --no-index to tell it not to use PyPI).
The files in question can still be found: just provide the direct url instead of the package name:
http://www.crummy.com/software/BeautifulSoup/download/3.x/3.0.8.tar.gz
for example.