I got some problems installing the contextBroker on my own server.
I got a CentOS installation. Im trying to install the contextBroker with yum.
I have setup the repo as discribed in (https://stackoverflow.com/a/24510985/4953537)
Output when trying to install:
yum install contextBroker
Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
* base: ftp.plusline.de
* epel: mirror.proserve.nl
* extras: mirror.softaculous.com
* updates: mirror.netcologne.de
No package contextBroker available.
Error: Nothing to do
Output of yum repolist
yum repolist
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: ftp.plusline.de
* epel: mirror.proserve.nl
* extras: mirror.softaculous.com
* updates: mirror.netcologne.de
repo id repo name status
base CentOS-6 - Base 4926
epel Extra Packages for Enterprise Linux 6 - i386 9467
extras CentOS-6 - Extras 34
mongodb MongoDB Repository 269
testbed-fi-ware Fiware Repository 108
updates CentOS-6 - Updates 864
repolist: 15668
What am i missing here?
Update:
cat /etc/yum.repos.d/testbed-fi-ware.repo
[testbed-fi-ware]
name=Fiware Repository
baseurl=http://repositories.testbed.fi-ware.org/repo/rpm/x86_64/
gpgcheck=0
enabled=1
"rpm -qa | grep contextBroker" doesnt give any output
Update:
I tryed to install the package manually and i installed all the dependancies listed on https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_Installation_and_Administration_Guide#Installing
The contextBroker package (mandatory) depends on the following packages: boost-filesystem, boost-thread, libmicrohttpd (new requirement in 0.8.0), logrotate (new requirement in 0.13.0), libcurl (new requirement in 0.14.1) and boost-regex (new requirement in 0.22.0).
Still, when installing the RPM package( sudo rpm -i http://repositories.testbed.fiware.org/repo/rpm/x86_64/contextBroker-0.22.0-1.x86_64.rpm) i get:
Failed dependencies:
ld-linux-x86-64.so.2()(64bit) is needed by contextBroker-0.22.0-1.x86_64
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libboost_filesystem-mt.so.5()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libboost_regex-mt.so.5()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libboost_system-mt.so.5()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libboost_thread-mt.so.5()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libc.so.6()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libc.so.6(GLIBC_2.2.5)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libc.so.6(GLIBC_2.3.2)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libc.so.6(GLIBC_2.3.4)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libcurl.so.4()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libgcc_s.so.1()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libgcc_s.so.1(GCC_3.0)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libm.so.6()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libm.so.6(GLIBC_2.2.5)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libmicrohttpd.so.10()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libpthread.so.0()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libpthread.so.0(GLIBC_2.2.5)(64bit) is needed by contextBroker-0.22.0-1.x86_64
librt.so.1()(64bit) is needed by contextBroker-0.22.0-1.x86_64
librt.so.1(GLIBC_2.2.5)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libstdc++.so.6()(64bit) is needed by contextBroker-0.22.0-1.x86_64
libstdc++.so.6(CXXABI_1.3)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libstdc++.so.6(GLIBCXX_3.4)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libstdc++.so.6(GLIBCXX_3.4.10)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libstdc++.so.6(GLIBCXX_3.4.11)(64bit) is needed by contextBroker-0.22.0-1.x86_64
libstdc++.so.6(GLIBCXX_3.4.9)(64bit) is needed by contextBroker-0.22.0-1.x86_64
Why do i get this?
Sometimes yum doesn't detect new packages in the repositories. In that case, I have found that the following command use to help:
yum clean all
next, try again
yum install contextBroker
Another way is installing directly from the repository with rpm command, e.g.:
sudo rpm -i http://repositories.testbed.fiware.org/repo/rpm/x86_64/contextBroker-0.22.0-1.x86_64.rpm
However, in this case, if some package dependency fails, you would need to deal with it manually.
EDIT: in the case of dependencies problems, you can use the following in order to know which package provides each dependency:
yum whatprovides libboost_filesystem-mt.*
yum whatprovides libstdc++.so.6
However, not sure if this would work in you case, given that the fail in yum install contextBroker at the very beginning makes me think if yum is not working fine in your environment...
Related
If you connect a github project to a product like cloudflare pages or Vercel, commits to the remote repo trigger new builds. These builds will run the appropriate install and build commands. I haven't updated a site in months, but major changes have come to dependencies being used and it's causing me so many headaches to try and go through one-by-one and address each and every issue that has surfaced. I'm using pnpm, is there anyway I can have pnpm install look at the existing pnpm-lock.yaml so I can eventually build a project that is entirely the same as a previous build I had 6 months ago? I just want to edit some text on my site and not have to make all these updates. I tried "freezing" the versions of all my dependencies and dev dependencies in package.json by removing instances of ^ to match what I see in my lock file, but that didn't work.
Package Management with PNPM
See also why-does-npm-install-rewrite-package-lock-json
Semver
The semver specification explains how to use semantic versioning though you can probably skip to the npm docs.
As you probably know the numbers are in the form major.minor.patch. If you don't mind which patch release you have as long as it is the specified major and minor version you can use the ~ prefix. Similarly, to allow any minor version use ^.
Walkthrough
Inital Setup
pnpm init
pnpm add express
The package.json will contain (at time of writing):
"express": `"^4.18.2"`
A pnpm-lock.yaml is also created:
specifiers:
express: ^4.18.2
dependencies:
express: 4.18.2
express -> '.pnpm/express#4.18.2/node_modules/express'/
Using pnpm install
Giving it a first run without changing anything produces:
$ pnpm install
Lockfile is up to date, resolution step is skipped
Already up to date
Done in 653ms
Now if I change package.json to be exactly v4.16.0 we shall see an update to pnpm-lock.yaml
specifiers:
express: 4.16.0
dependencies:
express: 4.16.0
Adding the patch wildcard ~4.16.0 and running pnpm install again gives:
specifiers:
express: ~4.16.0
dependencies:
express: 4.16.0
Note that the install version did not change. If I delete the node_modules/ directory and reinstall, still no change.
Ok, now try updating the minor version in package.json to ~4.17.0.
specifiers:
express: ~4.17.0
dependencies:
express: 4.17.3
This time it did update the dependency and installed the latest patch version but did install the exact major and minor version. If you think about what the ~ means then this is expected.
The specifiers section in the lock file is just what we specify as the dependency in the package.json file. The dependencies section in the lock file should reflect the version that is installed, or will be installed.
If I delete the node_modules/ folder and pnpm install again then we still have 4.17.3.
Explanation
What confuses a lot of people about pnpm install/npm install is how the lock-file works with the semver specifier:
The installed version listed as a dependency in the lockfile must be compatible with the version specified in the package file.
If it is compatible, no changes will be made.
If it is incompatible, then the latest compatible version will be installed.
Perhaps because sometimes it seems to install the latest version, and not othertimes, the behaviour is not clear. To state this again, changes will only be made when there is an incompatibility between the packge version and lockfile version. The lockfile dependency never has the ~ or ^ wildcards because only one version is actually installed and that's what the lockfile is supposed to track.
Using --frozen-lockfile in a CI environment
The docs for pnpm install describe how the install will fail if the lockfile is out of sync or needs updating.
Changing the package.json back to ~4.16.0 and then doing the install:
$ pnpm install --frozen-lockfile
Lockfile is up to date, resolution step is skipped
ERR_PNPM_OUTDATED_LOCKFILE Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json
Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"
In fact, even if I specify the installed version exactly 4.17.3, because it differs to the specifier ~4.17.0, then it will err. The package.json and pnpm-lock.yaml are out of sync even though the version are compatible.
Finally I will make our package compatible with the latest version that was installed with the first pnpm add express command. To do this I use the minor version wildcard ^4.0.0 and unfreeze the lockfile with pnpm install --no-frozen-lockfile.
specifiers:
express: ^4.0.0
dependencies:
express: 4.17.3
While the specifier is updated to match the package file, the version is not chaged; it is compatible.
Running pnpm install --frozen-lockfile will work again, but not update the installed version.
Conclusion
In a normal environment the lockfile will determine the exact version installed unless it is not compatible with the package file, in which case it will install the lastest version specified by the package file.
In a CI environment the lockfile will not by default be updated and will need to be compatible with the package file for installs to occur.
If you want the latest version specified pnpm update will do the update to the lastest compatible version given in the package file.
Disclaimer
I've tested out everything here but it is complex and I have limited experience using pnpm in a real CI environment.
before deploying your project delete pnpm-lock.yaml
[root#internalcrm ~]# yum update
Loaded plugins: etckeeper, fastestmirror, merge-conf
Repository 'remi-php74' is missing name in configuration, using id
Repository 'remi-php80' is missing name in configuration, using id
Loading mirror speeds from cached hostfile
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
Contact the upstream for the repository and get them to fix the problem.
Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
Run the command with the repository temporarily disabled
yum --disablerepo= ...
Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable <repoid>
or
subscription-manager repos --disable=<repoid>
Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: remi-php74
I use yarn to install packages directly from the companies' GitLab:
yarn add git+ssh://<user>#<host>:<repo>
For first-level dependencies, I use yarn --pure-lockfile to reconstruct my node_modules according to the yarn.lock.
However, for second level dependencies yarn seems to always install the latest version.
So let's say I depend on A which is tested with a specific version of B. In A's package.json I don't specify the version, but it is contained in the yarn.lock.
When I now install package A yarn will get the latest version of B despite the entry in A/yarn.lock
I know that I might resolve this by passing a specific version in A/package.json (at least I think).
But is there an option to tell yarn to look at the yarn.lock of dependencies?
TLDR:
When you install dependencies in your
application, only your own yarn.lock file is respected. Lockfiles
within your dependencies will be ignored. Reference
Let's get some things cleared first:
--pure-lockfile is same as normal yarn install except that it won't generate a yarn.lock file or update one if present.
Yarn always reads from the yarn.lock by default for resolving dependencies while installing unless supplied with --no-lockfile. So, there is no need to tell it to read from yarn.lock.
What is yarn.lock used for?
yarn.lock is used for resolving what version should be fetched
given the semver version of a module in package.json. It is not used to determine what semver version should a module be resolved to. That is simply not its use-case.
As mentioned in yarn DOCS: In order to get consistent
installs across machines, Yarn needs more information than the
dependencies you configure in your package json.. Yarn needs to store
exactly which versions of each dependency were installed.
To do this Yarn uses a yarn.lock file in the root of your project.
So, for resolving semver version of a dependency, yarn always depends on package.json. For a given semver version, yarn checks the yarn.lock file to see what version should it fetch. This is what makes yarn Deterministic (Same tecknique is used by npm which uses npm-shrinkwrap.json).
Example: Semver Versions like ^1.2.4 can resolve to any version number which is >= 1.2.3 and < 2.0.0. Without yarn, npm would install 1.2.4 in one machine but 1.9.9 in some other machine, depending on the latest version present at the time of install. This is the problem that yarn solves using yarn.lock.
The semver version is determined by the
package.json file. The yarn.lock file is only a lookup for which
version and commit hash to install for the given semver version number.
How does yarn resolve version of a module given its semver version?
Suppose currently our yarn.lock file looks like this:
bluebird#2.9.6:
version "2.9.6"
resolved "https://<...>/bluebird-2.9.6.tgz#1fc3a6b1685267dc121b5ec89b32ce069d81ab7d"
bluebird#^2.9.30:
version "2.11.0"
resolved "https://<...>/bluebird-2.11.0.tgz#534b9033c022c9579c56ba3b3e5a5caafbb650e1"
...
myModule#5.1.0:
version "5.1.0"
resolved "https://<...>/moduleA-5.1.0.tgz#ce97130858add59d616ee80675383b0c127290a0"
dependencies:
bluebird "^1.0.0"
If package.json has bluebird: "^2.9.30", yarn looks for an entry bluebird#^2.9.30 in the lockfile. It is present and hence is resolved to version=2.11.0.
If package.json has bluebird: "^2.9.0", yarn looks for an entry bluebird#^2.9.0 in the lockfile. It is not present. Suppose the latest stable version which satisfies semver criteria is 2.13.0, then yarn adds an entry for bluebird#^2.9.0, resolved to 2.13.0. While resolving version for a given semver version of bluebird, it does not matter what entry is present for bluebird in moduleA's dependencies in the lockfile.
Semver Version is not affected by what entries are
present in the dependencies map for a module in yarn.lock file.
So, if package.json has bluebird: "", yarn looks for an entry bluebird# in the lockfile but is unable to find it. Hence, it resolves bluebird: "" to the latest version, suppose 3.5.0. Now, yarn will add an entry for bluebird# resolved to 3.5.0.
bluebird#:
version "3.5.0"
resolved "https://<...>/bluebird-3.5.0.tgz#d9551f9de98f1fcda1e683d17ee91a0602ee2eb9"
Form now on whenever yarn encounters {bluebird: ""}, it will find an entry for bluebird# in the lockfile and hence will always resolve it to 3.5.0.
Solution to your problem
To resolve B: "" to version say 1.0.0, you need to have an entry for B# in yarn.lock resolved to 1.0.0. Once, yarn.lock has an entry for B#, all the successive installs will always fetch version 1.0.0 for B="".
Following are the steps you need to take to accomplish the same:
Approach 1 (Recommended)
If you want B to resolve to latest version:
Add B:"" in A's package.json
Run yarn install. This will add an entry for B# resolved to latest version.
Push yarn.lock file.
Form now on, whoever runs yarn install will get the same version.
Approach 2
If you want B to have an older version: (Highly Not Recommended)
Add B: 1.0.0 in A's package.json.
Run yarn install. This will add an entry B#1.0.0 in the lockfile.
Add B# alongside B#1.0.0 in yarn.lock. B#, B#1.0.0: ...
Change B's version to "" in A's package.json.
Push yarn.lock file.
Form now on, whoever runs yarn install will get the B's version as 1.0.0.
This approach is highly dangerous as you can break something easily. Your yarn.lock file should always be managed by yarn.
Approach 3 (Recommended)
If you want B to stay at 1.0.0
Fix B's version to 1.0.0 in A's package.json.
Run yarn install. This will add an entry B#1.0.0 in the lockfile.
Push yarn.lock file
Form now on, whoever runs yarn install will get the B's version as 1.0.0.
Edit: Using the yarn.lock file present in the dependencies
If you check this doc:, they have clearly mentioned that yarn will use only the top level yarn.lock file and ignore the lock files present in the dependencies.
There is currently no way of locking down second level dependencies using yarn.lock present in them. I don’t see any need for it. In fact the creators of yarn explain here why that is the case. The reasons being:
The versions to be installed for second level dependencies can be
captured well by the top-level yarn.lock file, as I have explained
above.
You would never be able to update the versions of sub-dependencies in your own application when using them directly because they would be locked by other yarn.lock files. You can verify this point by my explanation of how yarn resolves dependencies.
Yarn would never be able to fold (de-duplicate) dependencies so that compatible version ranges only install a single version.
Also, as in your use-case, if A has a dependency B which works only with version 1.0.0, A’s package.json should have version mentioned for B as 1.0.0 and not “”. You can always fix your top-level yarn.lock to add an entry for B# resolved to 1.0.0 but it is not recommended to manually fix a yarn.lock file as I have mentioned above.
Hope this helped! Please ping me in the comments for any doubts.
I have an npm package with a fixed version that has an update.
Example package.json extract:
devDependencies: {
"someFixedVersionPackage": "1.0.0", //1.1.0 is latest
"anotherFixedVersionPackage": "2.3.2", //2.3.4 is latest
}
Does an npm command exist which installs the latest version of that package and updates the package.json, preferably all packages at once?
To be clear, I want the package.json snippet above to be updated to this, in addition to the packages themselves being updated:
devDependencies: {
"someFixedVersionPackage": "1.1.0", //latest
"anotherFixedVersionPackage": "2.3.4", //latest
}
Thank you.
Why doesn't npm update work here?
As per the documentation on npm update:
This command will update all the packages listed to the latest version (specified by the tag config), respecting semver.
It will also install missing packages. As with all commands that install packages, the --dev flag will cause devDependencies to be processed as well.
Since your packages are defined with a fixed version, the update sub-command will not update those to respect semantic versioning. Therefore, it will only automatically update your packages if you specify a greater version range for each package. Note that it is actually typical in an npm project to specify a loose range version; one that is meant to avoid breaking changes but still leaves room for improvements and fixes.
Still, why shouldn't I fix dependency versions in my package.json?
But they are fixed because I wanted them so. After testing newer versions, I want to update them via command line as were created.
Having a list of dependencies with a fixed version does not mean that the dependencies installed will always be the same, because the dependencies of your dependencies will most likely also be defined with a version range. In order to keep track of a list of tested version-tagged dependencies, npm provides another mechanism: package locks.
Before version 5 of npm, you can create a "npm-shrinkwrap.json" file with the shrinkwrap command:
npm shrinkwrap
This command locks down the versions of a package's dependencies so that you can control exactly which versions of each dependency will be used when your package is installed.
Since npm 5, a "package-lock.json" is automatically generated when an npm operation modifies the "node_modules" tree or "package.json".
Rather than modifying package.json, either one of these package locks will override the default behaviour of npm install, installing dependencies with the versions specified by the lock, right when they were created or manually updated. With that out of the way, your dependencies can now be expanded without the risk of dependents installing untested package versions.
Shrinkwraps are used for publishing packages. To shrinkwrap a package:
Run npm install in the package root to install the current versions of all dependencies.
Validate that the package works as expected with these versions.
Run npm shrinkwrap, add npm-shrinkwrap.json to git, and publish your package.
At this point, dependency versions can be loosened in your package.json (this will hopefully be done only once every major dependency update), so that later on they can be updated at will with npm update:
"devDependencies": {
"someFixedVersionPackage": "^1.0.0",
"anotherFixedVersionPackage": "^2.3.2",
}
The package-lock.json file can be used instead of a shrinkwrap, and is more suitable for reproducing a development environment. It should also be committed to the repository.
So how do I update my dependencies?
Calling npm update will do what's mentioned above: update dependencies while respecting semantic versioning. To add or upgrade a dependency in a package:
Run npm install in the package root to install the current versions of all dependencies.
Add or update dependencies. npm install --save each new or updated package individually to update the package.json, as well as the existing package locks ("package-lock.json" and "npm-shrinkwrap.json"). Note that they must be explicitly named in order to be installed: running npm install with no arguments will merely reproduce the locked dependencies.
Validate that the package works as expected with the new dependencies.
Commit the new package locks.
Moreover, here are a few tips for a smooth transition from a project with fixed dependencies:
If you haven't done so, expand the version range by adding a tilde (~) before the version specifier, or a caret (^). npm update will then attempt to install all patch revisions and minor revisions, respectively (major version 0 is a corner-case, see the documentation). For instance, "^1.0.0" can now be updated to "^1.1.0", and "~2.3.2" can be updated to "~2.3.4". Adding the --save or --save-dev flags will also update the "package.json" with the installed version (while keeping the previous range specifiers).
Run npm outdated to check which packages are outdated. Entries in red will be updated automatically with npm update. Other entries will require a manual intervention.
For packages with major version bumps, install that package with a version specification (e.g. npm install browserify#11.2.0 --save-dev). Further issues that may arise with the update will have to be handled manually. It usually helps to read the news feed or the release history on that package to further understand what has changed from previous versions.
This is not simple enough, is there another way to do this?
Before continuing, it is always worth mentioning that packages have a SemVer-compliant version definition for a reason. One should avoid blindly installing the latest version of every single package. Although such a full update can be done and tools are available for that, some caution is advised. For instance, you would not want to install React 15 if the remaining React components and libraries are not compatible with react#15.x.x. See also npm's blog post: Why use SemVer?
I'll take my chances. What other tools are there?
To name a few:
npm-check-updates will do what was initially asked in the question: install and update the versions of all dependencies, regardless of the given range constraint. This would be the least recommended tool for the job, however.
updtr will update dependencies one by one and roll back to the previous version if the project's tests fail, which may save time in projects with good test coverage.
npm-check provides an interactive command-line interface, which allows you to easily select which packages to update.
Is this any different with npm 5?
Since major version 5, npm will automatically create a "package-lock.json", which will fill the role of specifying the dependency tree when a shrinkwrap does not exist. A more detailed description can be found in the package-locks documentation. In general, npm-shrinkwrap.json is meant to be used when publishing, whereas package-lock.json is to be used in development. This is why you should also commit "package-lock.json" to the repository.
What about with Yarn?
Yarn, an npm-compatible dependency manager, creates a lock file automatically on use, which behaves similarly to the npm shrinkwrap. Calling yarn upgrade «package» will update one dependency to the version in the latest tag, regardless of the version range recorded in the package.json or the lock file. Using yarn upgrade-interactive also allows you to selectively upgrade packages to the latest version, not unlike npm-check.
$ yarn outdated
yarn outdated v0.16.1
Package Current Wanted Latest
babel-eslint 7.0.0 7.0.0 7.1.0
chai 3.0.0 3.0.0 3.5.0
Done in 0.84s.
$ yarn upgrade babel-eslint chai
yarn upgrade v0.16.1
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 2 new dependencies.
├─ babel-eslint#7.1.0
└─ chai#3.5.0
Running the following command will do what you want:
npm install someFixedVersionPackage#latest anotherFixedVersionPackage#latest --save-dev --save-exact
Breakdown:
npm install someFixedVersionPackage#latest will install the latest version of the package
The --save-dev flag will cause it to update the version in your package.json's devDependencies
The --save-exact flag will cause it to save a fixed version instead of a semver range operator
Link to the npm install docs
I've been looking for an easy way to update npm dependencies for a long time. Then I found this tool: https://github.com/dylang/npm-check
It shows you which dependencies are out of date in a nice ui and allows you to update them. It even tells you which ones are likely to break due to major changes and warns you of unused dependencies.
I want to be able to compare my locally installed packages against my project package.json file without making a call against the npm online repo. If there is a package that is out of date based on the package.json file, then and only then will it go to the npm online repo and install the package.
The reason for this is that I want to be able to update the package.json file to require a newer version of a package, commit this change to the project repo and when other developers on the team get latest their npm package is updated. I do not want to slow down the process if everything is up-to-date or cause the build to fail if access to the npm repo or the internet is down.
I am wondering if this is an already solved use-case or do I need to parse the package.json file and compare it to a "npm ls" output myself?
you will need to setup a local repository (by duplicating the NPM couchdb localy)
( see https://stackoverflow.com/a/7577265/406458)
then you could use npm-check-updates.
npm-check-updates will give you a list of packages that can be updated in your package.json file see
https://www.npmjs.org/package/npm-check-updates
$ npm-check-updates
"connect" can be updated from 2.8.x to 2.11.x (Installed: 2.8.8,
Latest: 2.11.0) "commander" can be updated from 1.3.x to 2.0.x
(Installed: 1.3.2, Latest: 2.0.0)
Run 'npm-check-updates -u' to upgrade your package.json automatically
Check global npm packages for updates:
$ npm-check-updates -u