La siguiente guía es una lista de las mejores prácticas recopiladas y que generalmente recomendamos a todos los usuarios. No tome esta guía como obligatoria, eliga algunas recomendaciones según sus necesidades.
Feel free to suggest your best practices to the Verdaccio community.
Puede agregar usuarios y administrar qué usuarios pueden acceder a cuáles paquetes.
It is recommended that you define a prefix for your private packages, for example
local-* or scoped
@my-company/*, so all your private things will look like this:
local-foo. De esta manera puede separar claramente los paquetes públicos de los privados.
yaml packages: '@my-company/*': access: $all publish: $authenticated 'local-*': access: $all publish: $authenticated '@*/*': access: $all publish: $authenticated '**': access: $all publish: $authenticated
Always remember, the order of packages access is important, packages are matched always top to bottom.
Uso de paquetes públicos desde npmjs.org
If a package doesn't exist in the storage, the server will try to fetch it from npmjs.org. If npmjs.org is down, it serves packages from the cache pretending that no other packages exist. Verdaccio will download only what's needed (requested by clients), and this information will be cached, so if the client requests the same thing a second time it can be served without asking npmjs.org for it.
If you successfully request
firstname.lastname@example.org from the server once, you'll be able to do it again (with all of it's dependencies) any time, even if npmjs.org is down. Though note that
email@example.com will not be downloaded until it's actually needed by somebody. And if npmjs.org is offline, the server will say that only
firstname.lastname@example.org (what's in the cache) is published, but nothing else.
Anular paquetes públicos
If you want to use a modified version of some public package
foo, you can just publish it to your local server, so when your type
npm install foo, it'll consider installing your version.
Hay dos opciones aquí:
You want to create a separate fork and stop synchronizing with public version.
If you want to do that, you should modify your configuration file so Verdaccio won't make requests regarding this package to npmjs anymore. Add a separate entry for this package to
proxylist and restart the server.
packages: '@my-company/*': access: $all publish: $authenticated # comment it out or leave it empty # proxy:
When you publish your package locally, you should probably start with a version string higher than the existing package so it won't conflict with that package in the cache.
You want to temporarily use your version, but return to the public one as soon as it's updated.
In order to avoid version conflicts, you should use a custom pre-release suffix of the next patch version. For example, if a public package has version 0.1.2, you can upload
npm version 0.1.3-my-temp-fix npm publish --tag fix --registry http://localhost:4873
This way your package will be used until its original maintainer updates his public package to
Security starts in your environment. For such things we recommend reading 10 npm Security Best Practices and following the steps outlined there.
Acceso a Paquetes
By default all packages you publish in Verdaccio are accessible for all users. We recommend protecting your registry from external non-authorized users by updating the
access property of your packages to
packages: '@my-company/*': access: $authenticated publish: $authenticated '@*/*': access: $authenticated publish: $authenticated '**': access: $authenticated publish: $authenticated
That way, nobody can access your registry unless they are authorized, and private packages won't be displayed in the web interface.
email@example.com the tokens have no expiration date. For such reason we introduced in the next
firstname.lastname@example.org the JWT feature PR#896
security: api: jwt: sign: expiresIn: 15d notBefore: 0 web: sign: expiresIn: 7d
Al usar esta configuración invalidará el sistema actual y podrá controlar por cuánto tiempo vivirá el token.
Using JWT also improves the performance with authentication plugins. The old system will perform an unpackage and validate the credentials on every request, while JWT will rely on the token signature instead, avoiding the overhead for the plugin.
As a side note, at npmjs the token never expires.