SAP NPM packages now on npmjs.org
This post tells you what you need to know – and do – about the recent migration of SAP Node.js packages to the default registry at npmjs.org.
🚨See the Updates section for an important announcement.
Since 2017 SAP has made Node.js packages available at an SAP-specific registry https://npm.sap.com. Over the past few weeks the team has been busy migrating these packages to the default public registry https://npmjs.org.
Moreover, updates to SAP packages will in future only be available from the default public registry, and the SAP-specific registry will be phased out.
So now is the time to remove any NPM configuration you may have set to point to the SAP-specific registry for SAP packages.
Do it like this:
npm config delete @sap:registry
(If you’re on Windows, you may need to put the @sap:registry part in double quotes).
And you’re done!
The default package manager for Node.js is the Node Package Manager (NPM). Node.js packages (also referred to as NPM packages) can be made available publicly in registries. The main, default registry is at https://npmjs.org.
For organisational purposes, a package can belong to a scope (think of it as similar to a namespace). The scope starts with an @ sign and is joined to the package name with a slash. For example, the package
is in the @sap scope.
Combine this scope idea with the fact that there can be more than one registry (that’s why https://npmjs.org is called the “default” registry) and it means that it’s possible to, for example, have packages belonging to a certain scope published to and available at a different registry.
The (now retired) SAP NPM registry
This is the basis of what SAP did three years ago with the launching of the SAP NPM registry – see the post from Sven Kohlhaas back in 2017.
On your system, NPM will exist mainly as the command
npm, and when you ask it to install a package for you it will download the package from the registry associated with the specified scope.
Here’s an example (note that this is how it’s worked up until now, for illustration purposes):
npm install @sap/cds-dk
If there’s no specific association between the @sap scope and the SAP NPM registry where the package was available,
npmwould assume and use the default registry at https://npmjs.org.
So we’d set configuration for
npm to tell it to use a specific registry for @sap-scoped packages, like this:
npm config set @sap:registry=https://npm.sap.com
Now, with the recent migration of SAP packages to the main, default NPM registry at https://npmjs.org, while the @sap scoping of the packages remain, the configuration setting associating the @sap scope to the SAP-specific registry (https://npm.sap.com) is no longer required.
Not only that, but it’s no longer recommended either, as updates to SAP packages will only be made available on the default NPM registry and the SAP-specific registry will eventually disappear (see the Updates section).
Understanding and making the change
You can examine your NPM configuration with
npm config. Here’s an example from my machine right now:
▶ npm config list ; cli configs metrics-registry = "https://registry.npmjs.org/" scope = "" user-agent = "npm/6.14.4 node/v12.18.0 darwin x64" ; userconfig /Users/i347491/.npmrc @qmacro:registry = "https://npm.pkg.github.com" @sap:registry = "https://npm.sap.com" depth = 0 ; node bin location = /Users/i347491/.nvm/versions/node/v12.18.0/bin/node ; cwd = /Users/i347491 ; HOME = /Users/i347491 ; "npm config ls -l" to show all defaults.
The semicolon prefixed lines are comments, and the chunk of configuration in the middle is my user specific configuration (i.e. settings that I have made) which have been stored in an
.npmrc file in my home directory.
You can see two scope/registry settings. The first one is for my own @qmacro scoped packages which are on GitHub (see the GitHub packages feature for more information on this).
The second one is the current (and now unwanted) scope/registry association for SAP packages, there as a result of me running the
npm config set command at some stage in the past. It’s this association that needs to be removed (so that
npm will use the default NPM registry for any @sap scoped packages).
So let’s do this together now:
npm config delete @sap:registry
This will do exactly what we want, i.e. remove the configuration entry associating the @sap scope with the old (retired) SAP-specific registry.
Checking that the change took effect
npm operations referring to @sap scoped packages will use the default https://npmjs.org registry.
How do you check this? Of course, you can first just re-run the
npm config listcommand and check that the @sap:registry configuration line has gone.
You can also check this in a more interesting way by asking for information on an @sap scoped package, and checking that the information comes from the default NPM registry implicitly.
Here’s an example that you can try:
npm info @sap/cds-dk
This is what the output looks like on my machine right now:
▶ npm info @sap/cds-dk @email@example.com | See LICENSE file | deps: 10 | versions: 17 Command line client and development toolkit for the SAP Cloud Application Programming Model https://cap.cloud.sap/ keywords: cap, cds, cli bin: cds dist .tarball: https://registry.npmjs.org/@sap/cds-dk/-/cds-dk-1.8.5.tgz .shasum: 37673e772df6670b4a021943ef904919385c1b76 .integrity: sha512-mqNy5hDg8M8YeFhF0gjfDVGxrUhrojcbRqUV6rWMocRm8ZKbifFBd6syG56R49NUaiei9lZfsdTX6acOP3DzNg== .unpackedSize: 1.0 MB dependencies: @sap/cds-foss: ^1.2.0 @sap/edm-converters: ^1.0.30 nodemon: ^2.0.2 xml-js: ^1.6.11 @sap/cds-sidecar-client: ^1.1.3 express: ^4.17.1 passport: ^0.4.1 @sap/cds: 3.34.x mustache: ^4.0.1 sqlite3: 4.1.1 maintainers: - sap_extncrepos <firstname.lastname@example.org> - sapnaas <Holger.Brox@sap.com> - sapnaasuser <email@example.com> dist-tags: latest: 1.8.5 published 2 weeks ago by sap_extncrepos <firstname.lastname@example.org>
The details when you do this may look different as the versions, maintainers and dependencies change over time, but what you want to look for is the fully qualified domain name (FQDN) in the
This confirms that it’s the default registry that’s in play here.
For the curious
That’s about it for this post, but here’s a bit more information for the curious.
In case you’re wondering, the structure of the
npm command set is quite flexible, designed to fit how you think.
For example, with the
npm config setcommand earlier, the config word could have been omitted (i.e.
npm setworks too).
Some of you sharp-eyed readers will have noticed this comment in my configuration output:
; "npm config ls -l" to show all defaults.
In other words, instead of
npm config list you can use
npm config ls. Likewise, I could have used
npm config rm instead of
npm config delete.
And what about this configuration setting (which has nothing to do with package scopes or registries)?
depth = 0
It just tells
npm that when it’s showing me information on packages and their dependencies, don’t display any levels of package hierarchy in the output, as I usually just want to see the top level package information.
For example, I can easily see which packages I’ve installed globally, like this:
▶ npm list --global /Users/i347491/.nvm/versions/node/v12.18.0/lib ├── @email@example.com ├── firstname.lastname@example.org ├── email@example.com └── firstname.lastname@example.org
Without this depth setting in my configuration, the output would be a complex hierarchy that is detailed but not what I’m usually looking for:
▶ npm list --global /Users/i347491/.nvm/versions/node/v12.18.0/lib ├─┬ @email@example.com │ ├─┬ @firstname.lastname@example.org │ │ ├─┬ @email@example.com │ │ │ ├── firstname.lastname@example.org │ │ │ ├─┬ email@example.com │ │ │ │ └── firstname.lastname@example.org │ │ │ └── email@example.com deduped │ │ ├── @firstname.lastname@example.org deduped │ │ ├── @email@example.com │ │ └─┬ @firstname.lastname@example.org │ │ ├─┬ @email@example.com │ │ │ ├─┬ @firstname.lastname@example.org │ │ │ │ ├── @email@example.com deduped │ │ │ │ └── firstname.lastname@example.org deduped │ │ │ ├─┬ @email@example.com │ │ │ │ ├── firstname.lastname@example.org deduped │ │ │ │ ├── email@example.com [... and another 2600+ lines! ...]
(It’s rather pleasing to notice the use of the Rambda package here in the SAP Cloud SDK – but that’s a story for another time :-))
21 Oct 2021 The official retirement date for npm.sap.com is 28 Feb 2022. See Note 3109201 for details.
Always enjoyable to read your articles, thanks!
exçellenté! makes it both easier to maintain and find packages. now that also all CAP packages are there...oi, did someone say "open source"?!? 😉
Great read. For those having @sap:registry configured in the global npm config, use command npm config delete @sap:registry -g to have it properly removed.
At first I tried without the -g and wondered why the property was still there.
It helped me!
What about HANA XSA npm registry settings?
shall we change the SAPUPSTREAM_LINK env variable of di-local-npm-registry app or can we delete that env variable?
You should change or remove that setting as well.
Great blog! Thanks for the once again very clear information!
One thing I personally noticed following your blog, was that I had to change following command:
I encountered this issue on Windows (might not be needed on Mac OS or Linux)
Thanks – great tip, I've added it to the TL;DR section.
Firstly thank you very much for posting this information! This is a great information! I’m using node modules from sap registry quite heavily with the projects that I’m involve in.
I have a few questions on about this:
Thanks heaps once again!
ps – thank you, finally it might be a bit easier to see all the different publish versions without downloading it locally and hopefully this also is a sign of the documentation for each of the module to be clearer and better going forward. E.g how to use the different modules with examples, whether it is compatible with which Node version and etc.
You’re welcome Stefanus. I’ve relayed your questions to the team, here are their answers:
Thank you for all your posts!
SCP seems to use npm.sap.com yet:
Cannot find last @sap/cds 3.34.3:
And the hash of the package odata-server-1.8.2.tgz is the hash of the sap registry.
npm ERR! Verification failed while extracting @firstname.lastname@example.org:
npm ERR! sha512-MVGq3Ifw2H0QK0ObOxNZbsV5rtuboQ+bhXO7bT0W0P4R8HxivVA4oaDaMFk6d95EIJ96v4LamkGF989ZVsd+JQ== integrity checksum failed when using sha512: wanted sha512-MVGq3Ifw2H0QK0ObOxNZbsV5rtuboQ+bhXO7bT0W0P4R8HxivVA4oaDaMFk6d95EIJ96v4LamkGF989ZVsd+JQ== but got sha512-03uEuvvueLQ8gInYGK6loJ2+0n9h3Io3oPfBWe40bm2++9yqPCDIl7XfjaltbGU7ATLb15poT+jc7O3nSUtbgg==. (164145 bytes)
What's new: 🙂
In case somebody also still uses Web IDE (like many SAP customers), I found out it is possible to just add a .npmrc file to the root of your project with the following content:
This seems to override the somehow "hardcoded" SAP registry.
In case you have to build subfolders, then of course you need to add that file there as well, e.g. "srv" of a CAP project can be build via right click -> build, so you need to copy that file into this folder, too.
thanks for providing the summary including the history, that made the picture complete for me 😉
Just one question remains: we have reuse libraries we do not want to publish to the world but keep for our little projects (at least for the moment). Is there a way to restrict access to these libraries to, let's say, SAP origins - do you know that?
Thanks a lot
Hi Matze, not sure - but please get in touch via email and I can connect you to the team. Cheers. DJ