The latest Node.js v12 is required to run verdaccio. The upgrade only affects those are not using the Docker.

Verdaccio goes hand to hand with the official Node.js releases roadmap.

We recommend, always try to use the latest LTS version to avoid next major forces you to upgrade Node.js again.

Pino.js is the new logger

Verdaccio replaces Bunyan by Pino.js as logger, with the objective to improve the performance and delegate some features to the external tools. The new logger configuration does not support multiple streams, thus the configuration must contain one single object.

Pretty logging​

Verdaccio logging pretty print is a distinguished feature the very first time verdaccio commands runs.

 http <-- 200, user: test(127.0.0.1), req: 'GET /is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz', bytes: 0/3250
 http <-- 200, user: test(127.0.0.1), req: 'GET /extend-shallow/-/extend-shallow-3.0.2.tgz', bytes: 0/3210
 http <-- 200, user: test(127.0.0.1), req: 'GET /define-property/-/define-property-2.0.2.tgz', bytes: 0/4047
 http <-- 200, user: test(127.0.0.1), req: 'GET /mute-stream/-/mute-stream-0.0.8.tgz', bytes: 0/2663
 http <-- 200, user: test(127.0.0.1), req: 'GET /ms/-/ms-2.1.2.tgz', bytes: 0/3017
 http <-- 200, user: test(127.0.0.1), req: 'GET /mkdirp/-/mkdirp-0.5.1.tgz', bytes: 0/4991

But is expensive in and not recommended to using in production environment, thus, if the environment variable NODE_ENV=production is detected, it will fall back automatically to json format.

One tecnical reasons is that pino.final does not work with prettier option.

To improve the performance of your registry, always use format: json in production.

Multiple streams​

Even if is supported by Pino.js is not recommended for performance reasons. The log property only recognize one single option. If you were using this feature and want it back, feel free to open a discussion or contribute as opt-in feature.

logs: { type: stdout, format: pretty, level: http }

FYI: pino v7 might bring back a good performant multi-streams support, this feature might be restored in the future.

Rotating file is not longer supported​

Pino.js does not support log rotation, thus if you were using this feature is recommended use an external tool.

 // this is not longer valid
 {type: rotating-file, format: json, path: /path/to/log.jsonl, level: http, options: {period: 1d}}

Deprecation​

Old configuration won't crash the application, rather will display a deprecation warning and will use the very first option in your configuration as fallback. Consider update your configuration due in the next major will throw an error.

➜  verdaccio
 warn --- config file  - /home/xxxx/.config/verdaccio/config.yaml
(node:22047) Warning: deprecate: multiple logger configuration is deprecated, please check the migration guide.
(Use `node --trace-warnings ...` to show where the warning was created)
 warn --- Plugin successfully loaded: verdaccio-htpasswd
 warn --- Plugin successfully loaded: verdaccio-audit
 warn --- http address - http://localhost:4873/ - verdaccio/5.0.0-alpha.0

npm token​

The command npm token has been an experiment in Verdaccio 4 and on this major release is enabled by default, but was based on LevelDB which requires a C and Python compiler on install to make it work. By request has been removed and replaced by a pure JS solution.

The default token database now is plain json file .token-db.json and is located in the same directory as .verdaccio-db.json, with this format:

{
  "jpicado": [
    {
      "user": "jpicado",
      "token": "MWFlM...yZDBl",
      "key": "4201e4bc47c31b3434034e40b5c35175",
      "cidr": [],
      "readonly": false,
      "created": 1609512433710
    },
    {
      "user": "jpicado",
      "token": "ZjQwZ...wYTE1",
      "key": "cc249bc2f4d248308733d70291acdc2a",
      "cidr": [],
      "readonly": false,
      "created": 1609512441024
    }
  ],
  "test": [
    {
      "user": "test",
      "token": "M2RiM...0Mzhj",
      "key": "2ae85deba977e00fb099d323173c925a",
      "cidr": [],
      "readonly": false,
      "created": 1609533131779
    }
  ]
}

Tokens are not being storage, just small part of it, the key is just a random uuid.

Breaking Changes​

If you were using npm token in verdaccio 4, most likely the database would need to be removed and created from scratch. Remove the old database and on restart Verdaccio will generate a new one.

url_prefix improved behavior​

The new internal logic builds correctly the public url, validates the host header and and bad shaped url_prefix.

eg: url_prefix: /verdaccio, url_prefix: verdaccio/, url_prefix: verdaccio would be /verdaccio/

A new public url environment variable​

The new VERDACCIO_PUBLIC_URL is intended to be used behind proxies, this variable will be used for:

• Used as base path to serve UI resources as (js, favicon, etc)
• Used on return metadata dist base path
• Ignores host and X-Forwarded-Proto headers
• If url_prefix is defined would be appened to the env variable.

VERDACCIO_PUBLIC_URL='https://somedomain.org';
url_prefix: '/my_prefix'

// url -> https://somedomain.org/my_prefix/

VERDACCIO_PUBLIC_URL='https://somedomain.org';
url_prefix: '/'

// url -> https://somedomain.org/

VERDACCIO_PUBLIC_URL='https://somedomain.org/first_prefix';
url_prefix: '/second_prefix'

// url -> https://somedomain.org/second_prefix/'

Custom favicon, the new web.favicon property​

The favicon can be set either as url or absolute path in your system.

Local absolute path​

web:
  title: Verdaccio
  favicon: /home/user/favicon.ico

Ensure the same user that runs the server also has permissions to access the resource you define here.

By URL​

web:
  title: Verdaccio
  favicon: https://somedomain.org/favicon.ico

If the logo is not defined, will fetch (and bundled in) the custom verdaccio favicon

UI changes to consider​

The new UI may looks the same, but under the hood has consideriable changes:

• Does not contain any CSS, SVG or Fonts anymore: The UI is JS 100% based.
• It uses emotion and <styles> are generated on runtime by JS.
• Fonts now depends of your system, by default define a set of the most common ones.

Web new properties for dynamic template​

The new set of properties are made in order allow inject html and JavaScript scripts within the template. This might be useful for scenarios like Google Analytics scripts or custom html in any part of the body.

• metaScripts: html injected before close the head element.
• scriptsbodyBefore: html injected before close the body element.
• scriptsBodyAfter: html injected after verdaccio JS scripts.

web:
  scriptsBodyAfter:
    - '<script type="text/javascript" src="https://my.company.com/customJS.min.js"></script>'
  metaScripts:
    - '<script type="text/javascript" src="https://code.jquery.com/jquery-3.5.1.slim.min.js"></script>'
    - '<script type="text/javascript" src="https://browser.sentry-cdn.com/5.15.5/bundle.min.js"></script>'
    - '<meta name="robots" content="noindex" />'
  scriptsbodyBefore:
    - '<div id="myId">html before webpack scripts</div>'

UI custom plugins themes​

If you have a custom UI plugin for the them you will need to adapt your build to the new requirements.

The previous version you only need to return a function with a string and the path of the directory.

const path = require('path');

module.exports = () => {
  return path.join(__dirname, 'static');
};

Since Verdaccio 5 the module must return an object and the index.html is ignored since support dynamic rendering, eg:

  staticPath: '/somePath/node_modules/verdaccio-theme-custom/static',
  manifest: {
    'main.js': '-/static/main.c21a97b1dbe8456a9c76.js',
    'runtime.js': '-/static/runtime.c21a97b1dbe8456a9c76.js',
    'NotFound.js': '-/static/NotFound.c21a97b1dbe8456a9c76.js',
    'Provider.js': '-/static/Provider.c21a97b1dbe8456a9c76.js',
    'Version.js': '-/static/Version.c21a97b1dbe8456a9c76.js',
    'Home.js': '-/static/Home.c21a97b1dbe8456a9c76.js',
    'Versions.js': '-/static/Versions.c21a97b1dbe8456a9c76.js',
    'UpLinks.js': '-/static/UpLinks.c21a97b1dbe8456a9c76.js',
    'Dependencies.js': '-/static/Dependencies.c21a97b1dbe8456a9c76.js',
    'Engines.js': '-/static/Engines.c21a97b1dbe8456a9c76.js',
    'Dist.js': '-/static/Dist.c21a97b1dbe8456a9c76.js',
    'Install.js': '-/static/Install.c21a97b1dbe8456a9c76.js',
    'Repository.js': '-/static/Repository.c21a97b1dbe8456a9c76.js',
    'vendors.js': '-/static/vendors.c21a97b1dbe8456a9c76.js',
    '718.c21a97b1dbe8456a9c76.js': '-/static/718.c21a97b1dbe8456a9c76.js',
    '238.c21a97b1dbe8456a9c76.js': '-/static/238.c21a97b1dbe8456a9c76.js',
    '73.c21a97b1dbe8456a9c76.js': '-/static/73.c21a97b1dbe8456a9c76.js'
  },
  manifestFiles: { js: [ 'runtime.js', 'vendors.js', 'main.js' ] }

• staticPath: is the same data returned in Verdaccio 4.
• manifest: A webpack manifest object.
• manifestFiles: A object with one property js and the array (order matters) of the manifest id to be loaded in the template dynamically.

Manifest and Webpack​

Verdaccio uses the webpack manifest object to render the html dynamically, in combination with the manifestFiles the application understand what to render.

Currently only support js but if you also need css, we are open to discuss it and further improvements.

const { WebpackManifestPlugin } = require('webpack-manifest-plugin');

  plugins: [
    ...
    new WebpackManifestPlugin({
      removeKeyHash: true,
    }),
    ...
  ],

Troubleshooting

After upgrade I don't see packages on the UI​

This migth be the storage is not being located, if you are using this format in your config.yaml

storage: ./storage

Use an absolute path instead, more info here.

Today, I will explain how I migrated my private dockerized Verdaccio registry from v3.x to v4.x.

I will also configure verdaccio-ldap to authenticate my users against LDAP.

Working demo here

First of all, I wante to congratulate everyone who tested, contributed to Verdaccio v4 .

V4 include bunch of improvment, optimization, starting with the Web UI made completely redesigned with ReactJS and MaterialUI.

Not only that security has been improved with the introduction of the optional JWT, but v4 also bring a new feature to unpublish packages.

Let's upgrade it!

Prerequisite​

• Read verdaccio documentation.
• Read verdaccio-ldap documentation.
• A backup of your v3 storage directory (just in case).
• A running LDAP database (such as OpenLDAP).
• Docker installed.

Goal​

• Update Verdaccio from v3.x to v4.x.
• Configure LDAP.
• Configure JWT. (Read more)

Dockerfile​

This is my tree structure:

├── conf
│   └── config.yaml
└── Dockerfile

First thing I had to do was to update my Dockerfile, this is what I have done:

FROM verdaccio/verdaccio:4.3
USER root
RUN npm i && npm i verdaccio-ldap
COPY conf /verdaccio/conf
RUN chown -R $VERDACCIO_USER_UID /verdaccio
USER verdaccio

• v3.x is now using by default verdaccio user for security reason. This is why need to switch to root user to use npm.
• We install verdaccio-ldap but you can install any plugin. (Only if you don't want the verdaccio-htaccess builtin solution to be your user database)
• Later, you MUST solve the storage directory permissions and ownership.

Configuration​

This is my config.yaml:

storage: /verdaccio/storage
max_body_size: 100mb

web:
  enable: true
  title: My private NPM registry
  gravatar: true
  sort_packages: asc

security:
  legacy: false
  api:
    jwt:
      sign:
        expiresIn: 30d
        notBefore: 0
  web:
    sign:
      expiresIn: 7d
      notBefore: 1

auth:
  ldap:
    type: ldap
    client_options:
      url: 'ldap://ldap.verdaccio.private.rocks'
      # Only required if you need auth to bind
      adminDn: 'cn=readonly,dc=verdaccio.private,dc=rocks'
      adminPassword: '********'
      # Search base for users
      searchBase: 'dc=verdaccio.private,dc=rocks'
      searchFilter: '(&(uid={{username}})(memberOf=cn=npm_users,ou=npm,ou=groups,ou=developers,dc=verdaccio.private,dc=rocks))'
      # # If you are using groups, this is also needed
      groupDnProperty: 'cn'
      groupSearchBase: 'ou=npm,ou=groups,ou=developers,dc=verdaccio.private,dc=rocks'
      # If you have memberOf support on your ldap
      searchAttributes: ['*', 'memberOf']
      # Else, if you don't (use one or the other):
      # groupSearchFilter: '(memberUid={{dn}})'
      #
      # Optional, default false.
      # If true, then up to 100 credentials at a time will be cached for 5 minutes.
      cache: false
      # Optional
      reconnect: true

# a list of other known repositories we can talk to
uplinks:
  npmjs:
    url: https://registry.npmjs.org/

packages:
  '@scope-*/*':
    # scoped packages
    access: npm_access
    publish: npm_publisher
    unpublish: npm_publisher

  '@scope/*':
    # scoped packages
    access: npm_access
    publish: npm_publisher
    unpublish: npm_publisher

  '@*/*':
    # scoped packages
    access: $all
    publish: $authenticated
    proxy: npmjs
  '**':
    # allow all users (including non-authenticated users) to read and
    # publish all packages
    #
    # you can specify usernames/groupnames (depending on your auth plugin)
    # and three keywords: "$all", "$anonymous", "$authenticated"
    access: $all

    # allow all known users to publish packages
    # (anyone can register by default, remember?)
    publish: $authenticated

    # if package is not available locally, proxy requests to 'npmjs' registry
    proxy: npmjs

# log settings
logs:
  - { type: stdout, format: pretty, level: trace }
#  - {type: file, path: verdaccio.log, level: info}

listen:
  - 0.0.0.0:4873

Available options are explained in details in Configuration File documentation.

I will describe the most important here.

LDAP​

We use verdacio-ldap plugin to authenticate with LDAP.

searchFilter

I use the memberOf overlay, and this LDAP query will allow to connect only users present in a defined LDAP group.

If you are not using the memberOf overlay, you can allow all users to login as follow:

searchFilter: '(&(uid={{username}}))'

groupSearchBase

I use an organization unit to store all my group for verdaccio-ldap security.

groupSearchBase: 'ou=npm,ou=groups,ou=developers,dc=verdaccio.private,dc=rocks'

Security​

packages

You SHOULD use scope for all your privates packages, in this scenario, we use LDAP groups for access, publish and unpublish.

Note that we do not use proxy: npmjs because they only exist on our private registry.

I recommend you to create scope for all of your private packages, and reserve the group on npmjs registry so no one will be able to publish publicly in it in the futur.

'@scope-*/*':
  access: npm_access
  publish: npm_publisher
  unpublish: npm_publisher

'@scope/*':
  # scoped packages
  access: npm_access
  publish: npm_publisher
  unpublish: npm_publisher

They are some public package on npmjs registry which are scoped, this will proxy all the request to npmjs registry.

I recommend not to change this, otherwise you might get issue to download them.

'@*/*':
  # scoped packages
  access: $all
  publish: $authenticated
  proxy: npmjs

For all other packages, to prevent anyone to use our registry, we just allow $authenticated to publish. We also use proxy: npmjs so we also serve all the public package on npmjs registry.

We allow $all to download from our registry, because it is public, but if you want to preserve your bandwidth or just forbid unknown user to authenticate, just use $authenticated as well.

'**':
  access: $all
  publish: $authenticated
  proxy: npmjs

security

You should (and I recommend it) use JWT security, otherwise your LDAP server will received an authentication request for each request.

If you don't mind, you can keep legacy: true.

If you do use the JWT authentication, then all your users will have to re-authenticate with npm adduser.

security:
  legacy: false
  api:
    jwt:
      sign:
        expiresIn: 30d
        notBefore: 0
  web:
    sign:
      expiresIn: 7d
      notBefore: 0

• expiresIn: You will have to reauthenticate after 30 days, and 7 days on the web UI.
• notBefore: Just set it to 0, it is the time to wait before the JWT starts it's validity.

Build the image​

Use docker build to build the new image.

• -t will give the name verdaccio-3-ldap to the new image
• . means that the Dockerfile is in the current working directory.

$ docker build -t verdaccio-3-ldap .

Sending build context to Docker daemon  14.34kB
Step 1/7 : FROM verdaccio/verdaccio:4.3
4.3: Pulling from verdaccio/verdaccio
e7c96db7181b: Already exists
50958466d97a: Already exists
56174ae7ed1d: Already exists
284842a36c0d: Already exists
38829697cf41: Pull complete
67d4be407dc1: Pull complete
75921a7a709e: Pull complete
27621c093247: Pull complete
b5dd63eea3d5: Pull complete
3d5fd2ab9d4d: Pull complete
Digest: sha256:2a79d82601596f1889f2fe99d397c8900bf473c6682624cc0c37288896617e99
Status: Downloaded newer image for verdaccio/verdaccio:4.3
 ---> 03eefd251eef
# etc...
Step 7/7 : USER verdaccio
 ---> Running in 2426b01499b8
Removing intermediate container 2426b01499b8
 ---> 5e36f29f5374
Successfully built 5e36f29f5374
Successfully tagged verdaccio-3-ldap:latest

Your image is ready, you can push it to your private docker registry, or on Docker Hub if you can host private images.

Do not publish it publicly unless you remove all your LDAP credentials in the configuration.

To do so, remove the config.yaml within the Dockerfile:

FROM verdaccio/verdaccio:4.3
USER root
RUN npm i && npm i verdaccio-ldap
- COPY conf /verdaccio/conf
RUN chown -R $VERDACCIO_USER_UID /verdaccio
USER verdaccio

And mount the configuration on startup with a volume:

docker run -v $(pwd)/config.yaml:/verdaccio/conf/config.yaml verdaccio-3-ldap

Run the service​

You will have to mount the storage volume when using Docker, to do that, just use -v with docker run command:

docker run -v /srv/verdaccio/storage:/verdaccio/storage verdaccio-3-ldap

Remember, you have made a backup of your storage directory, now let's fix permissions and ownership to finish verdaccio migration.

Because within the docker container, the user is verdaccio, you can't run chown and chmod commands. Just do it directly from your host as root:

cd /srv/verdaccio/ # the location depend of your installation
chmod -R 777 storage
VERDACCIO_USER_UID=10001 # unless you have changed it
chown -R $VERDACCIO_USER_UID storage

Test the service​

First, fill appropriate LDAP group for all your LDAP users that should have access to the private npm registry.

We call $IP the IP address of the server. If you serve it over https behind a reverse proxy or directly, then fix all the following command to use the right protocol.

This is all the test I have done while configurating verdaccio, before going to production:

plugin​

• [x] it should work with verdaccio-htaccess when verdaccio-ldap is not installed.
• [x] it should work with verdaccio-htaccess when auth.ldap is disabled and verdaccio-ldap is installed.
• [x] it should work with one verdaccio-ldap.
• [x] it should work with verdaccio-htaccess and fallback to verdaccio-ldap through web.
• [x] it should work with verdaccio-htaccess and fallback to verdaccio-ldap through npm. Either use verdaccio-htaccess or verdaccio-ldap, it is useless to use both, even if the web work with the two, the npm --add-user command will fail.

npm​

• [x] npm --adduser should work with different users.
• [x] npm --adduser should fail with wrong user/password.
• [x] it should auth with JWT and the verdaccio-ldap plugin.
• [x] it should auth with legacy and the verdaccio-ldap plugin.
• [x] npm i in CI that download from the registry should spam the LDAP with authentication requests with legaxy.
• [x] npm i in CI that download from the registry should not spam the LDAP with authentication requests with JWT.

Web​

The new design with material-UI is super nice btw.

• [x] it should authenticate with different users.
• [x] it should fail to authenticate with different users and wrong password.
• [x] it should show packages to users with access permissions.
• [x] it should hide packages to users without access permissions.

Packages permissions​

• [x] access should work with a user with perms.
• [x] access should fail with a user without perms..
• [x] access should work with a user in ldap group with perms.
• [x] access should fail with a user not in ldap group with perms.
• [x] publish should work with a user with perms.
• [x] publish should work with a user in ldap group with perms.
• [x] publish should fail with a user not in ldap group without perms.
• [x] unpublish should work with a user with perms.
• [x] unpublish should fail with a user without perms.
• [x] unpublish should work with a ldap group with perms.
• [x] unpublish should fail with a user not in ldap group with perms.

Web​

• Test the web interface, generally http://$IP:4873 if you are not using a reverse proxy.

After login, you won't be able to see private scopped package if you don't have the access group.

npm​

Because we use the JWT, you must re-authenticate, this is how we do:

npm adduser --registry http://$IP --always-auth

If you want to use it just for a specific scope:

npm set @scope:registry http://$IP

If you want to use it as your default proxy for npm:

npm set registry http://$IP

Conclusion and thanks​

Docker, LDAP are a great way to authenticate users from your organization. In this article, you have learned how to setup verdaccion with LDAP and Docker.

I have to thank the teams and community behind verdaccio projects, specially Juan Picado, Daniel Refde and Sergio Hg for their help on the GitHub issues and the discord chat.

Also, but not less important, I want to thank all the people that makes Verdaccio possible, contributing, donating, documenting, and more.

I hope it is well explained and you people of verdaccio are able to reproduce a configuration that fit with your LDAP.

To me it took a while to figure out the different errors I had and the most annoying things was those manual step to fix the permissions and access.

If you have any question, please check at the FAQ below, or feel free to reply to this blog post.

If you 😍 Verdaccio as I do, helps them to grow by donating to the project via OpenCollective.

Thanks for reading and long life to Verdaccio !

FAQ​

• Can we use two authentication plugin together such as verdaccio-htaccess?

No you can't, but pull request are welcome.

• Does my registry users need to re-authenticate?

If you use JWT for authentication, which I recommend, they will all have to re-authenticate.

• I have 404 or 401 errors with good credentials.

This is due to wrong permissions or ownership in storage directory, dont forget to chmod -R 777 /verdaccio/storage and chown -R $VERDACCIO_USER_UID /verdaccio.

• When should I use --always-auth when running --add-user?

Since npm 7.10, the config option always-auth has no effect. You can safely remove it from your configuration.

Furthermore, the info about the release is also available at the GitHub releases page.

We have some highlights to share:

• At this stage, Docker 🐳 pulls have grown to 5.7 million pulls.
• We just reached 7.9k 🌟, would you help us to reach 10k? Give us your star ⭐️!
• Blog 🗒: Don't miss our new entry Managing multiple projects with Lerna and Yarn Workspaces by @sergiohgz.
• Monorepo: Along the last months we have crafted our monorepo for grouping all our ecosystem, plugin, core and tooling packages. This does not mean Verdaccio will become a monorepo, rather it will help us to grow without affecting the main repository and do easy updates or respond fast to mistakes in any release.
• Hacktoberfest 🎃 is here: We have prepared a guide if you want to contribute to Verdaccio, feel free to read it and give us feedback.

If you 😍 Verdaccio as we do, help us to grow more by donating to the project via OpenCollective.

Thanks for supporting Verdaccio ! 👏👏👏👏.

Use this version​

Docker​

docker pull verdaccio/verdaccio:4.3.0

npmjs​

npm install -g verdaccio@4.3.0

Experiment Flags​

This release includes a new property named experiments that can be placed in the config.yaml and is completely optional.

We want to be able to ship new things without affecting production environments. This flag allows us to add new features and get feedback from the community that wants to use them.

The features that are under this flag might not be stable or might be removed in future releases.

New Features​

Browse web packages by version by @juanpicado​

When you publish a new version of your package, you want to be able to access the previous ones, that's exactly what you can do with this new release.

Note the README always points to the latest release, Verdaccio does not persist the readme on each publish. This might change in the future, file a ticket if you are interested and might be considered if there is enough 👍🏻 votes.

npm token command support by @juanpicado, @Eomm and @juangabreil.​

The command npm token is really useful to generate multiple tokens. This release ships some partial support for it and is flagged as experiment, to enable it you must do the following in your config file.

experiments:
  token: true

You can find further technical information here.

Other updates​

• (Docker) Node.js update to v10.16.3 #1473 by @juanpicado
• (Logging) Ensure every log file has at least one record #1414 by @mlucool
• UI: fix: correctly load font files - closes #134 by @DanielRuf
• UI: fix(ui): fix the hover effect on the packageItem's author area #137 by @FilipMessa
• UI: chore: pumped mui version #131 by @priscilawebdev
• UI: fix: sidebar view on small screens #136 by @juanpicado
• Monorepo: fix(security): Cross-site Scripting (XSS) for readme #145 by @juanpicado
• Monorepo: remove eslint warnings #112 by @sergiohgz
• Monorepo: chore: use Alpine image in DevContainers #100 by @sergiohgz
• Monorepo: ci: publish every commit in a temporal in-memory registry #74 by @sergiohgz

Verdaccio v3

Verdaccio 3 is still under our security maintenance state, thus we just shipped a minor update v3.13.1.

• Docker image updated to Node.js v10.16.3
• Update core dependencies

We update as much as possible without breaking the current implementation, thus storage or htpasswd are not part of this update.

Use this version​

Docker​

docker pull verdaccio/verdaccio:3.13.1

npmjs​

npm install -g verdaccio@3.13.1

or

npm i -g verdaccio@previous

We saw a problem, these configurations entropy made harder to work with all the projects. So, we needed to simplify and unify them to make it easier. We need a monorepo.

A monorepo is a project configuration to manage a collection of dependencies in a simple and unified way. There are many examples out there that Javascript developer use nowadays, like Babel, Create React App or Material UI.

Now, we are proud to announce our monorepo, our big ecosystem joined in only one repository. This article is the first part of a series of articles where we will try to explain our motivation about to set up by your own, improve the management and workflows (CI, code quality, etc).

Background and tools​

A year ago, Juan and I met in Madrid, Spain, and were talking about the roadmap for Verdaccio 4, the scope of the projects and more. We had some concerns about the Verdaccio ecosystem we want to build, such amount of repositories requires hard work for maintenance by each one with their own dependencies, scripts, configurations, etc.

We decided to unify all configurations, because handle several repositories would not be realistic and would have all things replicated in all repositories. In order to achieve our goal, and we found Lerna and Yarn Workspaces.

As a first step, we created the basic architecture of the monorepo and moved the first dependencies in, an ESLint config and a Babel preset.

After Verdaccio 4 release, Typescript migration and more, we saw that many projects shares the same architecture, so it could be a good moment to achieve our goals.

There are more tools for this purpose, but we will focus on Lerna and Yarn Workspaces.

Lerna​

Lerna is a tool to manage several Javascript projects with multiple packages (called monorepos), optimizing the workflows around them.

You can install it globally with npm install --global lerna, yarn global add lerna or your favourite package manager, to run commands with lerna <command>. Also, if you don't want to install it, you can use package runners such as npx.

Yarn Workspaces​

Yarn Workspaces is a way to setup package architecture where all packages dependencies are installed together with a single yarn install.

This involves two things that you could not see at the first moment.

• All the packages in the workspace uses a common lockfile as a single source of truth.
• If a package has a dependency on other package in the workspace, they are linked without affecting your global environment.

Since Yarn 1.0, this feature is enabled by default, you only need a root package.json to setup them.

Creating the monorepo​

The initial setup is really simple, you only need to create a new repository and run lerna init to initialize the monorepo. This will generate files like package.json or lerna.json (packages structure is shown as example, but not generated).

lerna.json
package.json
packages/
├── pkg1
│   └── package.json
├── pkg2
│   └── package.json
└── pkg3
    └── package.json

Let's see the main configuration for lerna.json and root package.json.

lerna.json​

After initial setup, this file will looks like:

{
  "packages": ["packages/*"],
  "version": "0.0.0"
}

• packages: this array defines the location for all packages that conforms the monorepo. They could be explicit (packages/pkg1) or, if a folder has several packages, you can use * wildcard. In our case, we use core/*, plugins/* and tools/*.
• version: the version of the packages. It could be a semver value (called fixed mode) or independent if you want to let packages define their own version. Take care that independent mode will create one tag for each package that will be published with its own version. We prefer fixed mode to keep all packages with the same version and reduce headaches to users.

Other interesting settings are:

• npmClient: you can define in you want to use Yarn, Npm or your favourite client.
• useWorkspaces: if you want to enable Yarn Workspaces, you will have to tell it to Lerna, setting this option to true.
• stream: if you want to have the output of a child process inmediately in the console, you have to enable this option. Also, this will prefix each line with the package name that generate them.

package.json​

After initial setup, you need some configuration to allow Lerna work with Yarn Workspaces:

• workspaces: this is the array where we define the packages that are part of the workspace. In a simple way, this is the same you have defined in lerna.json under the packages key.
• private: as the root package should be a simple container, you should keep it with true value to not publish it.

Later, you will learn how to define more settings in the root package.json.

Creating and importing packages​

You have a monorepo, but it's not useful at this moment. Let's create and import some packages.

lerna create​

To create new packages, you can use lerna create <package_name> like you would do with npm init or yarn init. The wizard will ask you for some fields like package description, author or license. Other way to give that information is using command options (--description, --author, etc).

Then, you have the package ready for work with it, add stuff like Babel or ESLint, dependencies and scripts to package.json...

It's important to say that if your package is a scoped package, you have to add the next codeblock in package.json, but do not add it if your package is not scoped, because lerna publish will fail in this case:

"publishConfig": {
  "access": "public"
}

lerna import​

If you have a project you want to import, you don't have to create a new one in the monorepo, you can import it using lerna import <path_to_project>.

This command will read all the Git history from the project specified and apply commit-by-commit into your monorepo to avoid losing the original history. If there were commits with conflicts, the import process will fail, but CLI propose you to use the --flatten option to bypass it. Also, if you want to keep original authors and committers, you can pass --preserve-commit option.

After the import completes, you can remove unnecessary stuff like CI settings, old scripts, hoisted devDependencies...

Managing dependencies and devDependencies​

Each package will contain their own dependencies and devDependencies like if the package is not in a monorepo, but there are some interesting things you can do with devDependencies, hoist them in the root package.json.

Let's see with an example, pkg1 and pkg2 defines ESLint as devDependency, so you have defined that in two packages, duplicating the definition and management. You can extract it from both and set it as devDependency in the root package.json. This way, all the projects that need it will have it available. Now, we are going to add ESLint to pkg3, you only have to add its own configuration, because package has been hoisted right now.

But the same doesn't work with dependencies, because they are needed when the package is published.

A good practice is to hoist every devDependency so they will be available for every package, except in two cases:

• A package needs a specific version of the package. In this case, you can have a root definition for all the packages and the specific version for the package that requires it. This will create a node_modules for the specific package, but not another yarn.lock.
• Those devDependencies that are part of the workspace must not be defined in the root package.json, because if you do that, you will create a cycle. An example is if pkg1 and pkg2 define pkg3 as devDependency, it could not be defined in the root because pkg3 will depend with itself.

Running scripts​

Like dependencies, each package will have their own scripts, so you should define them in their specific package.json.

But what happens when you want to run scripts for many packages at the same time? You don't need to extract them to the root package.json because they will contain specific arguments/options for each project. You can invoke scripts or commands from the root package using two Lerna commands, lerna run and lerna exec.

The first, lerna run <script>, will perform the script provided looking for what packages have it defined in their packages.json. This command is useful when you want to build package or run tests, because not all packages would have them defined.

The second, lerna exec <command>, will execute the command (not script) in all the packages. This is useful if you want to run tools like ESLint in all the packages and you have it installed globally. In this case, the command invoked must be in your system PATH (ls, cat, npm binaries, etc).

Both commands shares options like --scope=<packages> and --ignore=<packages>, where the first will run only in packages specified and the last will ignore them.

Versioning the monorepo​

As we mentioned in lerna.json section there are two versioning ways for packages in monorepos: fixed mode and independent mode.

We will focus in fixed mode because:

• We want to use the same version for all the packages in the ecosystem.
• Independent mode creates one git tag for each package and version in each release. With the example before, in a release we will create three tags, pkg1@0.1.0, pkg2@2.1.0, pkg3@0.5.2. In larger codebases you will create more than 10 tags at the same time.

In fixed mode, the version set in the lerna.json is a reference for all the packages but, if a package has no changes between releases, that package will not be published except when the version bump is major (from X.Y.Z to X+1.0.0).

Because Lerna is going to manage the versioning, you should change your mind to use lerna version and lerna publish commands.

• lerna version will update version for the packages that has changes from the release (you can review with lerna changed). This will launch a wizard except if you pass the version or a semver keyword (major, minor, patch, etc) as the first argument or use Conventional Commits (see below). This command updates version in all affected packages, commit changes, create tags and pushes to the remote automatically.
  Also, you can use --conventional-commits option if your commits follows Conventional Commits spec, automating the changelog generation. Additionally, for Github and Gitlab users, you can use --create-release <github | gitlab> to create release with changes. Keep in mind that you have to provide an auth token (GH_TOKEN or GL_TOKEN).
• lerna publish will act as lerna version and publish packages if you don't provide from-git or from-package arguments, or only publish if provide one. You would like to use from-git to version first, using Git as a single source of truth.

Conclusion and thanks​

Lerna and Yarn Workspaces are a great combination for creating monorepos. In this first part, you have learned how to setup a monorepo, add packages, improve dependency management, scripts and versioning. In the next chapters, you will see more configuration and tooling (and their settings for monorepos), and how to automate some things using Continuous Integration tools.

We have to thank the teams and community behind both projects, specially Henry Zhu and Daniel Stockman for Lerna, and Maël Nison for Yarn. Also, but not less important, we want to thank all the people that makes Verdaccio possible, contributing, donating, documenting, and more.

If you 😍 Verdaccio as we do, helps us to grow more donating to the project via OpenCollective.

Thanks for support Verdaccio ! 👏👏👏👏.

We have some highlights to share:

• At this stage, Docker downloads have grown to 5.1 million pulls.
• New Verdaccio Monorepo development has begun early this month, we are migrating small repositories, plugins and other tools to create a unique ecosystem, feel free to contribute. This first steps are developed by @sergiohgz with the contributions of @griffithtp.
• We finally migrated all repositories to Typescript, we do not support Flow types anymore.

If you 😍 Verdaccio as we do, helps us to grow more donating to the project via OpenCollective, this project is addressed by voluntaries, help us to be sustainable.

Thanks for support Verdaccio ! 👏👏👏👏.

Use this version​

Docker​

docker pull verdaccio/verdaccio:4.2.0

npmjs​

npm install -g verdaccio@4.2.0

New Features​

Typescript migration by @juanpicado, @priscilawebdev and @griffithtp​

Now, Verdaccio is built entirely in Typescript, the last phase was convert the main project.

The UI-Theme was also migrated to Typescript by @priscilawebdev with the help of @griffithtp for finishing the refactor and make ESLint looks great again.

audit module doesn't support strict_ssl flag by @dfrencham​

There are some scenarios where Verdaccio runs behind company proxy with self-certificates. Now the audit middleware supports the flag strict_ssl, replicating the same feature availabe in uplinks.

middlewares:
  audit:
    enabled: true
    strict_ssl: true # optional, defaults to true

Development​

prevent secrets from leaking to source control by @lirantal​

Adds support through detect-secrets which wraps Yelp's generic detect-secrets tool, to test for secrets being committed to source control using the pre-commit Git hook the project already has, and as a result prevent secrets like passwords, tokens and others to leak into source control.

The detect-secrets npm package will try different methods of invoking the detect-secrets-hook tool to run the secrets test for each file, and if it isn't able to find it will silently fail to not interrupt developer workflow. In a future re-visit of this capability we can update this to be a breaking change and fail the commit (or perhaps fail the CI, which might be a bit late, but better than never).

storage plugins can throw http status codes by @juanpicado​

The storage plugins were forced to return some specific error codes that are not part of Node.js. Now we allow storage plugins to return the same error codes that Verdaccio returns to the Node Package Manager. Read more context in the PR.

Bugs​

• Download button is not displayed if the tarball dist URI has localhost as domain by @juanpicado
• download button hidden for localhost by @griffithtp

Furthermore, the info about the release is also available at GitHub releases page.

We have some highlights to share:

• At this stage, Docker downloads have grown to 4.8 million pulls.
• Angular CLI just started to uses Verdaccio 4 for E2E testing. For further read about this topic, check our docs.
• This release has been fully developed by contributors, kudos to them.
• We just reached 7k stars, would you help us to reach 10k? Give us your star ⭐️!
• We have a new Security Policy Document 🛡, helps us to keep Verdaccio secure for their users.

If you 😍 Verdaccio as we do, helps us to grow more donating to the project via OpenCollective.

Thanks for support Verdaccio ! 👏👏👏👏.

Use this version​

Docker​

docker pull verdaccio/verdaccio:4.1.0

npmjs​

npm install -g verdaccio@4.1.0

New Features​

Filter plugin for packages by @mlucool​

Verdaccio now support plugin filters, we are just starting with filter metadata.

It gets a current copy of a package metadata and may choose to modify it as required. For example, this may be used to block a bad version of a package or add a time delay from when new packages can be used from your registry. Errors in a filter will cause a 404, similar to upLinkErrors as it is not safe to recover gracefully from them.

The configuration would looks like

filters:
  storage-filter-blackwhitelist:
    filter_file: /path/to/file

The current API for the plugin is

interface IPluginStorageFilter<T> extends IPlugin<T> {
  filter_metadata(packageInfo: Package): Promise<Package>;
}

This system might be extended in the future, we are trying this approach at this stage.

parse YAML/JSON/JS config file by @honzahommer​

Now, Verdaccio is able to understand JSON format for configuration files.

verdaccio --config /myPath/verdaccio.json

New CLI command verdaccio --info by @jamesgeorge007​

The new verdaccio --info command will display information of your environment, this sort of information is handy in order to report any bug.

$ verdaccio --info

Environment Info:

  System:
    OS: macOS 10.14
    CPU: (4) x64 Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz
  Binaries:
    Node: 10.15.0 - ~/.nvm/versions/node/v10.15.0/bin/node
    Yarn: 1.16.0 - ~/.nvm/versions/node/v10.15.0/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v10.15.0/bin/npm
  Virtualization:
    Docker: 19.03.0 - /usr/local/bin/docker
  Browsers:
    Chrome: 75.0.3770.100
    Firefox: 67.0.3
    Safari: 12.0
  npmGlobalPackages:
    verdaccio: 4.0.0

You can install and upgrade to the latest version by following commands:

using npm

npm install -g verdaccio@4.0.0

or using Yarn

yarn global add verdaccio@4.0.0

or using pnpm

pnpm install -g verdaccio@4.0.0

You can find detailed installation instructions here

Why 'Freedom' ?​

Verdaccio originated from Sinopia almost three years ago and since then the Verdaccio Team maintaining and releasing major release every year. Since the fork, the project has evolved in many ways, making the project’s code base modern, easier to debug and more straightforward to contribute.

The name Freedom holds true meaning for Verdaccio@4.x release. Verdaccio is a strong community of many contributors and developers from across the world, providing an ideal platform for everyone to give control of their code. Also, Verdaccio@4.x is free from tech debt of legacy code and stands on design patterns of the modern era which consist React, Typescript, JWT, Docker & Kubernetes. We can call it Freedom in true sense.

Let's take a quick look at the life cycle and development of Verdaccio community:

• Verdaccio (version 2 - Release name: Birth) - Focused on stability, code quality, improvement in architecture of the old Sinopia project and community development.

• Verdaccio (version 3 - Release name: Hope) - Redesigned the user interface in React and introduced the simplicity of the plugins development. The Verdaccio Team and many contributors made the project almost bug free and robust. This was the time the project started to grow and other projects started using it.

Verdaccio@4.x is coming up with many exciting new CLI commands for package management, Fast and responsive user interface, security upgrades and easy deployments.

Excited?? Yes !!! Let's go !!

So what's changed? TL;DR​

• New User Interface
  • New search Process
  • Register Information
  • Packages
  • Detailed Page
  • Package Sidebar
• New Browser Router APIs
• Unpublish Role
• Disable Gravatar
• New CLI Commands
  • npm star
  • npm profile
• JWT Token
• Docker Improvements
• Drop Node 6 Support
• Plugins
• Tech Updates
  • Verdaccio ESLint Config
  • Verdaccio Babel Preset
  • Verdaccio UI Plugin
  • Meetup & Conferences
• Trusted by Many
• New to Verdaccio / FAQ / Contact / Troubleshoot

New User Interface​

Verdaccio@4.x comes with a new shiny appealing user interface, providing more details to show and easy to navigate. We did major changes in Verdaccio web application and everything is designed from scratch.

New Search Process​

Verdaccio@3.x has a limited search functionality and it was implemented on the browser side. Verdaccio@4.x provides fast and quick search results from the backend.

Register Information​

The Register information is easily accessible and can be seen by clicking on information icon in header.

Packages​

The new Package card provides more information about a package, easy to open issues and documentation link without navigating into package details.

Order: Verdaccio@4.x has basic support for package ordering from config.yaml. The package list can be sorted ascending & descending. Find out more

Detailed Page​

The new Detailed package in a more categorized manner for readme, dependencies, version and uplinks.

Package Sidebar​

The Package Sidebar includes most relevant information from package metadata. You can open an issue, see Readme and download the package tarball. It also clearly shows the package's minimum requirements on node and npm.

Also, The package sidebar shows Author, Maintainers and Contributors in different sections. When you click on person avatar, you'll be able to contact that person via email.

New Browser Router​

Till, verdaccio@3.x we have Hash Router implementation on frontend application routes. We faced a lot of problem with hash router in the Readme section. The Readme also uses (#) hash for the heading tags and anchor elements.

In Verdaccio@4.x, we migrated the Hash Router to Browser Router with a more cleaner look. (No more hashes in URLs).

Unpublish Role​

Verdaccio@4.x improves package management by adding an access layer to publish and unpublish. Now you can have restrictions to some of the users for publishing and unpublishing. Find out more

Disable Gravatar​

Verdaccio uses Gravatar to show the images of authors, contributors and maintainers. Now, gravatar support can be disabled from Verdaccio config.yaml.

web:
  title: Verdaccio
  gravatar: false

In order to be fully offline, The fallback support is a generic user face SVG based on base64.

New CLI Commands​

We are really excited to add some npm cli commands to Verdaccio. Now you can use npm star, and npm profile.

npm star​

Now a user can mark their favorite package.

npm star [<package>..]

npm profile​

With npm profile, a user can change their profile settings.

Note: Verdaccio does not support two-factor authentication yet.

npm profile get [--json|--parseable] [<property>]
npm profile set [--json|--parseable] <property> <value>
npm profile set password

Check out more at https://docs.npmjs.com/cli/profile

JWT Token​

Verdaccio supports JSON Web Tokens for the authentication. The previous version of Verdaccio used AES token generator. The new JWT token standardizes the process and provides an additional mechanism for token generation. Verdaccio@4.x still supports the AES token generator.

Click here for more information on new JWT tokens

Docker Improvements​

There is no doubt that Docker has been a major breakthrough for this project, it's by far the most popular way to download Verdaccio, we have more than 4.200.000 downloads at this writing and for such reason, we care about improving the developer experience adding new features.

Please click here more information on the new Docker Image.

Drop Node 6 Support​

NodeJS 6 went to end of life on April 30, 2019. Verdaccio@4.x drops the support for Node 6 & npm 3. Now on, Node 8 & npm 5 will be the minimum requirement. Verdaccio@4.x also checks for the minimum node version. https://github.com/verdaccio/verdaccio/pull/968

Plugins​

Verdaccio extends its functionalities with a set of plugins. You can find detailed information in Plugins Documentation

Tech Updates​

Verdaccio 4 heavily relies on plugins and provides APIs for developers to build their own plugins. We introduced few major changes in the development environment to adapt code modularity, decoupling and typed system.

Now the main Verdaccio module is a powerful CLI to package management and a plugin system to introduce new functionalities.

Verdaccio ESLint config​

Now on, Verdaccio Team uses @verdaccio/eslint-config across all the repositories to maintain the same coding style.

Verdaccio Babel Preset​

As Babel@7 released in 2018, Verdaccio Team updated babel dependencies to the latest. We also created a central repository for the Babel preset @verdaccio/babel-preset

Verdaccio UI Plugin​

Verdaccio provides an easy configuration system to enable/disable of web application. Verdaccio is used as End-to-End(E2E) tooling system in many platforms and shipping UI along with Verdaccio is a non-beneficial overhead. So we separated the UI module and it's repository for simple & easy development and maintainability.

You can find UI repository here.

Meetup & Conferences​

Since Verdaccio@3.x release, Verdaccio contributors are actively participating in community activities, conferences, meetup and on twitter.

• Dot Conference 2018, Paris
• React day 2018, Berlin
• JS Heroes 2019, Cluj Napoca ∙ Small talk ∙ Presence
• ViennaJS Meetup
• Madrid NodeJS Meetup
• Hacktober Fest 2018

Trusted by Many​

Verdaccio Team is very happy to share that following projects are using Verdaccio as their End-to-End (E2E) testing tool.

• create-react-app
• Storybook
• Gatsby
• Uppy
• Aurelia Framework
• bit
• pnpm
• Mozilla Neutrino
• Hyperledger Composer

New to Verdaccio / FAQ / Contact / Troubleshoot​

We welcome you in Verdaccio community and we look forward for your feedback and contribution to the project.

If you have any issue you can try the following options, do no desist to ask or check our issues database, perhaps someone has asked already what you are looking for.

• Blog
• Donations
• Roadmap
• Reporting an issue
• Running discussions
• Chat
• Logos
• FAQ
• Docker Examples

This article will describe what has changed, all the improvements and benefits you will enjoy from migrating to the latest version.

What’s new?​

Keep it small​

The new image is three times smaller than the previous, shrinking down from 500MB to 150MB. We achieved this level of optimization by using multi-stage build which allows excluding dependencies and assets not required for the runtime.

Environment Variables​

To avoid mistakes we have renamed all environment variables to be prefixed with VERDACCIO_. This will avoid future collisions and give a better understanding of the origin of the variable. Here is the full list of the new variables available in the new image.

Support Arbitrary User IDs​

The previous image runs the container with the verdaccio user and group by default, being the UID created randomly within the image. Some users were experiencing issues since some environments require the usage of custom user IDs for security reasons. To support this, we have introduced the environment variable VERDACCIO_USER_ID.

Furthermore, other optimizations can be possible, as for instance, define a different username using VERDACCIO_USER_NAME and such user won’t have permissions to log in by default.

Security​

We have followed security recommendations to remove write permissions to those locations that do not need to be modified for the default user.

For instance, the code written to /opt/verdaccio. The verdaccio run user cannot modify the compiled resources, nor config. Only the /verdaccio/storage volume. The image only assigns executable permissions to the binary executable required to run verdaccio.

If you are not using volumes, the VERDACCIO_USER_NAME will only have permissions to write in the storage folder and the source code. The configuration and plugins will be read only.

To provide your own configuration file, the recommended way is using Docker volumes like so:

V_PATH=/path/for/verdaccio; docker run -it --rm --name verdaccio \
  -p 4873:4873 \
  -v $V_PATH/conf:/verdaccio/conf \
  -v $V_PATH/storage:/verdaccio/storage \
  -v $V_PATH/plugins:/verdaccio/plugins \
  verdaccio/verdaccio:4

We use the user ID 10001 for the run user and assign the root group to the locations that need to be written to by the run user. If running in a normal environment, the specific ID is used and permissions are correct. If running on a randomized user ID environment like openshift, the non-existent user gets assigned the root group and is allowed write access to relevant locations.

The entrypoint will add the user to /etc/passwd in case the user is running as a random uid (openshift). That way, the typical tools like whoami and so can still work.

Conclusions​

This new image has been tested in production for months and is quite stable, thus there is no need to worry about giving it a try. We have improved in several areas but there is still a lot to do and for that we need you. If you are DevOps do not hesitate to give us your feedback or contribute directly in discussions and future PRs to take the Verdaccio Docker image to the next level. We count on you.

Contributions​

We want to thank Diego Louzán, Dimitri Kopriwa, Sergio Herrera, Ben Tucker, Michiel De Mey and me Juan Picado for this amazing job improving the Docker image.

Without forgetting the Helm Chart contributors, James Sidhu, Carlos Tadeu Panato Junior, Bort Verwilst, ercanucan and Taehyun Kim that have keep the Kubernetes integration alive during the last year.

If you are already using Verdaccio 4 you are can immediately use the new token signature support with JWT or JSON Web Tokens.

npm install -g verdaccio@next

This article will explain what are the advantages of using JWT instead of the traditional or legacy token signature used by Verdaccio. But before that, we need to be int he same page about ** JWT.**

I’d recommend reading the following article before continue the reading.

5 Easy Steps to Understanding JSON Web Tokens (JWT)

Context​

Verdaccio 3 uses by default a token signature are based on AES192 encryption, that has been a legacy implementation inherited by Sinopia.

This token signature consists of the combination of user:password signed using a SALT secret key. Every time a resource is requested, the client package manager will send this token within the request if the user is logged in and will decrypt and send it through the authentication plugin to validate the credentials.

This might create a bit of spamming due Verdaccio is a stateless RESTful API and it is likely no caching involved in the authentication process.

This has been working fine so far, but, some users do not need to check credentials for every request , for such reason, we decided to ship on a new way to sign tokens giving a different set of rules the users can structure their authentication process.

JWT does not replace the current token signature system, thus, no breaking changes come on Verdaccio 4, both systems are completely different and by demand, but you need to decide to use only one of them.

Setup​

By default, the AES192 or legacy system is being used by default and we do not have plans to remove it.

If you want to enable JWT, just add into your configuration file the new property security .

security:
  api:
    legacy: false
    jwt:
      sign:
        expiresIn: 60d
        notBefore: 1
      verify:
        algorithm:
        expiresIn:
        notBefore:
        ignoreExpiration:
        maxAge:
        clockTimestamp:
  web:
    sign:
      expiresIn: 7d

api and web​

The security section is composed by in two main sections. Each section will use same JWT properties but the configuration structure is different. The web section does not have to deal with legacy support, thus, will group sign and verify properties directly as children.

While the api section contains a different level of properties, we will go through them in the next sections.

legacy​

Legacy property means that explicitly you want to use the legacy token system signature. You might not like to do not remove the whole security section in order to disable JWT and for such reason, this property exists.

The rule is simple, if legacy is true, will be enabled it even if the jwt exist. But, if you do not want to use legacy just do not declare it or just set it as false .

jwt​

To enable JWT you need to append the property jwt within the api section.

Similar as the web section inside of security also contains different options for sign and verify.

Signature and Verify​

The options for sign or verify defined inside of either web or apiare well explained in the section by the jsonwebtoken library from Auth0.

You can use them freely according to your needs, Verdaccio will just delegate whatever you define within such sections directly to the jsonwebtoken library.

Legacy vs JWT​

If you are happy with the current signature, we recommend keeping it, but if there are some differences you might need to know.

If you are interested to expire tokens , use a different algorithm , JWT fits more in your needs.

JWT also contains an immutable payload, meaning that, once the token is being signed, we store the list of assigned user groups within the payload. Thus, for each request the API does not verify credentials against the authentication provider, it just verifies whether the token is valid and provides access to the resource. It is important to highlight that the JWT payload does not contain sensitive information as email or password.

In the other side, if you are interested to have full control of the credentials, the legacy signature might be better for you. In such a case, it is important to remind the token delivered is the combination of sensitive information signed with a SALT key and the authentication provider will be hit for each resource requested.

Conclusion​

We have tried to provide different methods of the token signature according to your needs, the JWT looks promising and will be an optional feature for Verdaccio 4.

Let us your feedback, any concern or advice is very welcome.

verdaccio/verdaccio

I would like to finish with a reminder that Verdaccio is a FOSS product which has as a unique backup the community of developers working in their spare time.

If you are willing to support the project, feel free donate over OpenCollective.

https://opencollective.com/verdaccio

Enjoy Verdaccio 4 ** 🤓**

Thanks, Luiz Filipe Machado Barni for the contribution to this article.

Migrating from sinopia@1.4.0 to Verdaccio 2.x/3.x​

If you are using still using Sinopia, we encourage you to migrate as soon as possible due to Sinopia has been abandoned.

Installation with npm​

Using as example UNIX environments, the local storage is located within ~/.local/share/ folder.

We support only sinopia@1.4.0 as minimum version, these are the steps:

1. The folder ~/.local/share/sinopia must be renamed to ~/.local/share/verdaccio
2. The folder ~/.config/sinopia must be renamed to ~/.config/verdaccio

There is an aditional step, not required, but recommended:

3. The file ~/.config/sinopia/storage/.sinopia-db.json must be renamed to ~/.local/share/verdaccio/storage/.verdaccio-db.json

To find the Windows location, check the following link.

Using Docker​

This might depends of your own configuration, but, if you are using external volumes we recommend following the step 3 in the previous section.

Migrating from verdaccio@2.x to verdaccio@3.x​

Those versions are fully compatible, so there is not a specific step for migrating between both of them. But we recommend the following considerations:

• Try to update first to the latest v2.x as possible. There were a lot of fixes and you might hit a corner case migrating from a very old version.
• We recommend using the latest v3.x available version.

Migrating from verdaccio@3.x to verdaccio@4.x​

Here you can read more about summary o of changes by Diego Louzán.

Installation with npm​

There are no differences between both major releases if you install with npm. The migration should be clean and painless.

If you decided to use the JWT token signature instead of the legacy one, all the client side tokens will be invalidated.

Installation with Docker​

Environment Variables​

The Docker image for version 3 allows the following environment variables:

Version 4 brings more control over the environment variables and provides a namespace to avoid collisions and new additions.

Docker and Plugins​

If you are using the Docker image as base with the purpose of installing plugins, there are some differences you need to keep on mind.

In Verdaccio 3 was really easy to install plugins, for instance:

FROM verdaccio/verdaccio:3

RUN npm i && npm install verdaccio-ldap

Rather in Verdaccio 4, the image has changed considerably and now you need to deal with the right folder permissions.

You can find more info about this in this ticket.

To install plugins, you need to use the right users for it, which is root.

⚠️ This approach works, but perhaps is no the best one, feel free to suggest modifications.

FROM verdaccio/verdaccio:4

## switch to root user
USER root

ENV NODE_ENV=production

## perhaps all of this is not fully required
RUN apk --no-cache add openssl ca-certificates wget && \
    apk --no-cache add g++ gcc libgcc libstdc++ linux-headers make python && \
    wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub && \
    wget -q https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.25-r0/glibc-2.25-r0.apk && \
    apk add glibc-2.25-r0.apk


RUN npm i && npm install verdaccio-[YOUR-PLUGIN-HERE]

# switch back to the verdaccio user
USER verdaccio

Once you have installed the plugin, it needs to restore the user, either the default one verdaccio or the one defined under the environment variable VERDACCIO_USER_NAME.

Sinopia “The Origin”​

A few years ago in 2013, the main registry (npmjs) was running for a while and at the same time, Alex Kocharin decided to create Sinopia.

The original objective was to create a Private registry and Cache to reduce latency between npmjs and the private registry. By that time npmjs was starting to struggle with their own performance issues and be able to host private packages were not supported yet.

In fact , Sinopia was created before the big npm fall of November 4th and much after the first registry was running. That incident put on the spotlight that having a packages proxy/cache registry in-house makes total sense, at the same time the project evolved adding interesting features as scopes packages, search on UI, plugins, override public packages etc.

It was clear the project was growing, but something happened in October 2015 where is the date of the latest commit and Alex which is still the current owner decided do not reply to anyone anymore, the reasons are unknown and seem will remain like that forever (he has recent activity in other projects) and since is the unique owner the project remains frozen.

Post-sinopia Era​

Early 2016 the Sinopia community started to wonder why so that such good idea with good support just stopped for no reason.

A few months later forks did not take long to appear. The most prominent forks were the following (I’m aware there were much more than these):

• Sinopia2: Maybe the most affordable and updated fork which seems to be intended with the idea to merge some PR were in the queue. Still, today seems on having some development but no further new features.
• shimmerjs/sinopia: A try from IBM team contributors to provide sinopia with CouchDB support. They did a couple of releases but no much development since the fork (this idea was a PR at Verdaccio for a long time but never was merged).
• npm-register: A inspired sinopia fork but created from scratch focused as to be hosted on PaaS services.
• verdaccio : And here is where all started, the 0 km started on 5 April 2016 which the “baptism” by cuzzinz suggesting the name that he read on Wikipedia.

Since it will be a fork, follow the subject the original project used but a new “color.” …. verdaccio

Verdaccio as fork​

After a couple of months without anyone taking the wheel of the ship John Wilkinson and Trent Earl created the Verdaccio organization on April 2016.

Originally the project was just another fork but soon started to receive the updates from the PR were in hold in sinopia for a long time and even changes committed on Sinopia2. There was a feeling of lack of commitment and confusion with all the forks, somehow this issue was well addressed by the Verdaccio authors providing a second breath to the project.

And here is where I came in. August 2016 is where I started to contribute as anyone else, my initial role was to fix the unit testing on Node 6 and stabilize the project in a couple of areas helping Trend to answer questions on the forum and work side to side to release the first stable version of Verdaccio v2.0.0 which was the first try to put some order in the project.

If you ask me why I decided to contribute Verdaccio. The reason is I liked the name.

During the fall of 2016 and beginning of 2017, we noticed more adoption and bug reports, but in February 2017 the original authors gave me the ownership of Verdaccio just before v2.1.1 release and they have stepped away of development and currently are just watcher. Nowadays I still feel super happy and grateful for the opportunity to drive this project.

As a side note, in that time, my experience with Node.js was not far away from beginner level even if I had good JS background (I’m a front-end developer until today in my private work experience), I’ve never had the chance to work with Node.js in any workplace, funny huh 😅?. What I learnt about real Node.js development is 100% due Verdaccio and reading open source code.

During early 2017 the project had only ~600 stars and I started to coordinate new contributions and a progressive migration to a modern codebase. I have to highlight the new ideas Meeeeow that brought to the project as semantic commits, the new UI based on React and other interesting things.

When you fork a project GitHub reduces the visibility on Google and Github searches , for that reason I asked Github about it. They kindly removed the fork label that we had for 1 year in our main repository.

2017 ended with a decent amount of stars (~1,200), thousands of downloads and a new logo, but still, we were not able to do a major release. There were too much to do and lack of knowledge in many areas.

Docker​

By that time, Docker was new for me until I saw the first time the Dockerfile and was getting so many tickets related with such topic that forced me to learn really quick to be able to merge contributions which were Chinese for me, what did I do?. Go to Docker meetups and read books. Problem solved. Thankfully the community has a lot of knowledge to share in this area thus I had the opportunity to learn from amazing contributions. Nowadays Docker is the most popular way to use Verdaccio even over the npm installation.

2018 “the year”​

I have to admit 2018 was super crazy since the first month the project got really good news and advertised by someone really popular (yeah, that helps a lot) Thanks Dan Abramov. create-react-app started to use as E2E tooling, which was totally new for me that scenario and changed our perspective of this project, later on, followed by another projects as Storybook, pnpm, Eclipse Theia, Hyperledger or Modzilla Neutrino.

At the same time, we released a new website at the beginning of the year which nowadays is insanely popular and has reduced the questions over Github being for users the first line of information, by the way, we were one of the early adopters of Docusaurus. Thanks to Crowdin that have provided a platform for translation and nowadays the community has released 7 full translations of our documentation.

By that time a new contributor was getting super active since 2017, Ayush which was using Verdaccio at work. In the beginning, his feedback was useful for real-time usage and nowadays he is also one of the authors for the success of this project in 2018.

After some crazy months working really hard, we manage at May to release Verdaccio 3. That gave us a small pause to rethink what to do as future steps and how to improve our community.

Also, we have boarded Sergio Herrera Guzmán and Priscila Oliveira that have demonstrated a lot of interest about Verdaccio contributing with awesome features as the new release pipeline and the new UI which will be released in 2019. The project currently has ~150 contributors and we are welcoming the new ones with open arms.

I’ve seen written articles about Verdaccio in multiple languages, conference speakers recommending the usage of Verdaccio, generous donations and our chat at Discord more active than ever.

To finish the story and ending 2018 we have created what we defined as the core team, a small group of developers trying to work together in the development of Verdaccio 4.

Current Status​

If you wonder how the “governance” works at Verdaccio, we do it in the following way. We have 4 owners (the founders, Juan Picado, Ayush) which we open communication when something important should take place and we ship an internal report every 6 months at GitHub teams threads. We have decided this structure in order to avoid what happened with Sinopia do not happen again. The development decisions are taking at the core team level based on democracy and common sense.

The development communication happens over Discord and we started to encourage code reviews and open discussions about everything. For now, it works, but we are trying to evolve the process and improve it.

Currently, we are working on improving the documentation and create a clean ecosystem of plugins, integrations and new ways to inform, teach new adopters about the usage of the registry and helping to board new contributors that want to be part of the development.

Wrapping Up​

As you have read, Verdaccio is not a one author project. It’s a collaboration of many developers that decided don’t let this project die. I always like to think the following if you allow me to quote a simile famous words of Abraham Lincoln

Verdaccio is a project of the community, by the community and for the community.

I’m driving this project today, but does not means I’ll do it forever. I like to share responsibilities with others because nobody is working on Verdaccio full time as it happens with other open source projects.

We want this project alive, updated and as reliable, open source and free option for everybody. Following the principles of sinopia stablished as simplicity, zero configuration and with the possibility to extend it.

Even if some initial developers are not contributing anymore (all we have a life), I’m really grateful for the time they have invested and hoped they back in some point.

Disclaimer​

I’m telling this story based on my own research and all the information collected along the latest 2 years, comments, private chats, and social networks.

This time for simplicity I’ve chosen DigitalOcean that provides affordable base prices and if you want to run your own registry, it’s a good option.

Create a Droplet​

Create a droplet is fairly easy, it just matters to choose an image and click on create, I personally selected a Node.js 8.10.0 version to simplify the setup.

While the droplet is created, which takes a matter of seconds the next step is to find a way to log in via SSH, you can find credentials in your email. Keep on mind the droplet provides root access and the next steps I won’t use sudo.

Installing Requirements​

As first step we have to install Verdaccio with the following command.

npm install --global verdaccio

We will use npm for simplicity, but I’d recommend using other tools as pnpm or yarn.

We will handle the verdaccio process using the pm2 tool that provides handy tools for restarting and monitoring.

npm install -g pm2

Nginx Configuration​

To handle the request we will set up ngnix which is really easy to install. I won’t include in this article all steps to setup the web but you can follow this article.

Once nginx is running in the port 80, we have to modify lightly the configuration file as follow

vi /etc/nginx/sites-available/default

location / {
 proxy\_pass [http://127.0.0.1:4873/](http://127.0.0.1:4873/);
 proxy\_set\_header Host $http\_host;
}

You might pimp this configuration if you wish, but, for simplicity this is good enough for the purpose of this article.

Don’t forget restart nginx in order the changes take affect.

systemctl restart nginx

Since we are using a proxy, we must update the default configuration provided by verdaccio to define our proxy pass domain. Edit the file and add the your domain or IP.

vi /root/verdaccio//config.yaml

http\_proxy: http://xxx.xxx.xxx.xxx/

Running Verdaccio​

Previously we installed pm2 and now is the moment to run verdaccio with the following command.

pm2 start `which verdaccio`

Note: notice we are using which due pm2 seems not to be able to run a node global command.

Using Verdaccio​

Verdaccio provides a nice UI to browse your packages you can access via URL, in our case get the IP from the DigitalOcean control panel and access verdaccio like http://xxx.xxx.xxx.xxx/ .

Install packages​

npm will use the default registry on install, but we are willing to use our own registry, to achieve that use the --registry argument to provide a different location.

npm install --registry http://xxx.xxx.xxx.xxx

Other options I’d suggest if you need to switch between registries is using nrm, to install it just do

npm install --global nrm
nrm add company-registry [http://xxx.xxx.xxx:4873](http://xxx.xxx.xxx:4873/)
nrm use company-registry

With the steps above, you can switch back to other registries in an easy way, for more information just type nrm --help .

Publishing Packages​

By default verdaccio requires authentication for publishing, thus we need to log in.

npm adduser --registry http://xxx.xxx.xxx.xxx

Once you are logged, it’s the moment to publish.

npm publish --registry http://xxx.xxx.xxx.xxx

Wrapping Up​

As you can see, host a registry is quite cheap and the initial set up might take fairly short time if you have some skills with UNIX.

Verdaccio provides you good performance for a small middle team with the default plugins, you might scale for bigger teams if is need it, but I will write about those topics in future articles.

If you are willing to share your experience in our blog writing about verdaccio being installed on other platforms, just send me a message over our chat at Discord for easy coordination.

What’s new in Verdaccio 4 Alpha? 🐣​

Tokens 🛡​

Improve security is one of our main goals, we have wanted to improve in one of the most important areas for the users, tokens. Currently the token verification is based on unpack the token for each request and ask the plugin whether the author is authorized. This might be a bit overwhelming if the authentication’s provider is not good handling a big amount of request or is totally unnecessary.

For that reason we are shipping a new way to generate token based on JSON Web Token (JWT) standard. This feature does not replace the current implementation and will remains as optional. To enable JWT on API is quite simple as we show in the following example.

security:
 api:
 jwt:
 sign:
 expiresIn: 60d
 notBefore: 1
 web:
 sign:
 expiresIn: 7d

We will allow to customize JWT by demand, for instance, allowing to expire tokens. We will go deep into the new JWT system in future articles.

Change Password 🔐​

Perhaps the most asked question in our forum and a so trivial action that might be no a problem nowadays. We have listen the community and invested time in this important feature.

npm profile set password -ddd --registry http://localhost:4873/

We allow change password via CLI using the npm profile . Currently the support is limited to the htpasswd built-in plugin, but in some point the plugin developers will take advance of this support.

Keep it update 🛰​

We want to help you to keep it updated, for that reason we are shipping a CLI notification that display the latest stable version available.

New UI 💅🏻​

We are aware that our UI has been simple, but we decided it is the time to scale it up in order to add new features. For that reason we planed a migration to a new UI toolkit that will help ups to achieve that goal, Material-UI.

As a first step we migrated the current UI improving the header. But that’s not all is coming, we have big incoming plans in the next alpha releases, for instance:

• Change password from UI
• i18n
• Improvements in the detail page

We are open to new ideas, feel free to suggest or share your thoughts during this development phase.

Docker 🐳​

We have reduced the size of the image and following the best practices adding a namespace VERDACCIO_XXX_XXX for environment variables. Many other new things are planned for our popular image that to this day we have almost 2,5 millions pulls.

Future 🔮​

I’d like to share our roadmap wether you are interested to know what is in our TODO list and you invite you to contribute or drop your thoughts in any of our channels, we like to listen feedbacks.

verdaccio/verdaccio

How to install​

npm install -g verdaccio@next

or using Docker

docker pull verdaccio/verdaccio:4.x-next

⚠️We highly recommend don’t use alpha versions 🚧in production, but if you are willing to test, always do a backup of your storage and config files. In any case, we are really careful with our deployments and are always highly reliable, but, we are humans after all.

However, if you are using Verdaccio 3, there are some small breaking changes you should keep on mind, specially for those are using environment variables with Docker, all details here.

Contributions and Community 🌍​

Verdaccio is an open source project, but also we aims to be a nice community and I’d like to introduce you the team that grain by grain is crafting this amazing project.

Verdaccio · A lightweight private npm proxy registry

We thanks all contributors, either via GitHub or translations, any contribution is gold for us.

Donations 👍🏻​

I’d like to reminder our readers that there are other ways to contribute to this project becoming a backer. Furthermore, all contributors are voluntaries and nobody is working full time on this project, but we are aware is getting bigger and deserves some promotion.

verdaccio - Open Collective

For those are already backers and sponsors, thanks so much 👏👏👏.

If you have the chance to meet any of our team members, feel free to ask for stickers (hopefully they will carry some), we use our budget mostly for promotion and you can help us to spread the voice, give your start or just recommend with your colleagues how great is Verdaccio.

Wrapping Up 👋🏼​

If you live near Vienna (Austria), we will have a presentation in early next year (January 2019) at ViennaJS meetup, feel free to join us if you want to know more about this project.

ViennaJS January 2019 - Meetups - ViennaJS Monthly Meetups

A future core team meeting will take place between 29th and 30th November at Berlin , we are attending React Day Berlin, feel free to DM if you want to have a chat to any of us.

Lockfiles on node package manager (npm) clients are not a new topic, yarn broke the node package managers world with a term called determinism providing a new file generated after install called yarn.lock to pin and freeze dependencies with the objective to avoid inconstancies across multiple installations.

If you are using a private registry as Verdaccio, it might be a concern committing the lock file in the repo using the private or local domain as registry URL and then someone else due his environment is not able to fetch the tarballs defined in the lock file.

This is merely an issue that all package managers have to resolve, nowadays is not hard to see companies using their own registry to host private packages or using the Verdaccio the power feature uplinks to resolve dependencies from more than one registry using one single endpoint.

How does a lock file look like?​

Lock file looks different based on the package manager you are using, in the case of npm as an example looks like this

"[@babel/code-frame](http://twitter.com/babel/code-frame)@7.0.0-beta.44":
 version "7.0.0-beta.44"
 resolved "[http://localhost:4873/@babel%2fcode-frame/-/code-frame-7.0.0-beta.44.tgz#2a02643368de80916162be70865c97774f3adbd9](http://localhost:4873/@babel%2fcode-frame/-/code-frame-7.0.0-beta.44.tgz#2a02643368de80916162be70865c97774f3adbd9)"
 dependencies:
 "[@babel/highlight](http://twitter.com/babel/highlight)" "7.0.0-beta.44"

The snippet above is just a small part of this huge file which nobody dares to deal when conflicts arise. However, I just want you to focus on a field called resolved.

Simple example with Verdaccio as localhost​

Let’s imagine you are using Verdaccio and yarn for local purposes and your registry configuration points to.

yarn config set registry http://localhost:4873/

After running an installation, yarn install, a lock file is generated and each dependency will have a field called resolved that points exactly the URI where tarball should be downloaded in a future install. That meaning the package manager will rely on such URI no matter what.

In the case of pnpm the lock file looks a bit different, we will see that in detail later on this article.

// yarn.lock

math-random@^1.0.1:
 version "1.0.1"
 resolved "[http://localhost:4873/math-random/-/math-random-1.0.1.tgz#8b3aac588b8a66e4975e3cdea67f7bb329601fac](http://localhost:4873/math-random/-/math-random-1.0.1.tgz#8b3aac588b8a66e4975e3cdea67f7bb329601fac)"

Let’s imagine you that might want to change your domain where your registry is hosted and the resolved field still points to the previous location and your package manager won’t be able to resolve the project dependencies anymore.

A usual solution is to delete the whole lock file and generate a new one , but, this is not practical for large teams since will drive you to conflicts between branch hard to solve.

So, How can I use a private registry avoiding the resolved field issue?. All clients handle this issue in a different way, let’s see how they do it.

How does the resolved field is being used by …?​

npm uses a JSON as a format for the lock file. The good news is since npm@5.0.0 ignores the resolved field on package-lock.json file and basically fallback to the one defined in the .npmrc or via --registry argument using the CLI in case is exist, otherwise, it will use the defined in the resolved field.

Nowadays you can use the npm cli with lock file safely with Verdaccio independently the URL where tarball was served. But, I’d recommend to share a local .npmrc file with the registry set by default locally or notify your team about it.

If you are using Yarn the story is a bit different. Until the version 1.9.4, it tries to resolve what lock file defines as a first option.

There are some references on PR, RFCs or tickets opened were they discuss how to address this problem properly and if you are willing to dive into this topic allow me to share the most interesting threads you might follow:

• Replace resolved field by hash https://github.com/yarnpkg/rfcs/pull/64#issuecomment-414649518
• yarn.lock should not include base domain registry https://github.com/yarnpkg/yarn/issues/3330
• Remove hostname from the lock files https://github.com/yarnpkg/yarn/issues/5892

TDLR; Yarn 2.0 has planned to solve this issue in the next major version, to this day sill discussing what approach to take.

pnpm follows the same approach as other package managers generating a lock file but, in this case, the file is being called shrinkwrap.yaml that is based in yaml format.

dependencies:
 jquery: 3.3.1
 parcel: 1.9.7
packages:
 /@mrmlnc/readdir-enhanced/2.2.1:
 dependencies:
 call-me-maybe: 1.0.1
 glob-to-regexp: 0.3.0
 dev: false
 engines:
 node: '\>=4'
 resolution:
 integrity: sha512-bPHp6Ji8b41szTOcaP63VlnbbO5Ny6dwAATtY6JTjh5N2OLrb5Qk/Th5cRkRQhkWCt+EJsYrNB0MiL+Gpn6e3g==
 tarball: /@mrmlnc%2freaddir-enhanced/-/readdir-enhanced-2.2.1.tgz

....

registry: '[http://localhost:4873/'](http://localhost:4873/')
shrinkwrapMinorVersion: 9
shrinkwrapVersion: 3
specifiers:
 jquery: ^3.3.1
 parcel: ^1.9.7

The example above is just a small snippet of how this long file looks like and you might observe that there is a field called registry added at the bottom of the lock file which was introduced to reduce the file size of the lock file, in some scenarios pnpm decides to set the domain is part of the tarball field.

pnpm will try to fetch dependencies using the registry defined within the lockfile as yarn does. However, as a workaround, if the domain changes you must update the registry field manually, it’s not hard to do but, is better than nothing.

pnpm has already opened a ticket to drive this issue, I’ll let below the link to it.

Remove the "registry" field from "shrinkwrap.yaml" · Issue #1353 · pnpm/pnpm

Scoped Registry Workaround​

A common way to route private packages is route scoped dependencies through a different registry. This works on npm and pnpm

registry=[https://registry.npmjs.org](https://registry.npmjs.org/)
@mycompany:registry=http://verdaccio-domain:4873/

It does exist any support for at the time of this writing.

In my opinion, this is just a workaround, which depends on the number or scopes you handle to decide whether or not worth it. Furthermore, the package manager will bypass those packages that do not match with the scope and won’t be resolved by your private registry.

Conclusion​

package managers are working to solve this issues with backward compatibility and with good performance.

For now, the best solution if you share this concern is using npm until the other clients decide what to do or following the recommendations above for each client.