End of Node.js 12 support, cannot guarantee due dependencies updates.
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Juan Picado <juanpicado19@gmail.com>
update core dependencies (7.x) no breaking changes, just internal bump up to prepare a major release (6.x)
🐛 fix fix: local search keyword undefined errors #3992🐛 fix Missing "onClick" prop in @verdaccio/ui-components Link component preventing handleDownload call in Package.tsx #3988#3989
The [`node:alpine` Docker image][1] adds some symlinks to `yarn` in
`/usr/local/bin/`. These should be removed as part of removing `yarn`
from the Verdaccio Docker image, otherwise there will be errors when
a someone tries to re-install `yarn` in their Docker image that builds
on top of the Verdaccio one.
[1]: 02a64a08a9/18/alpine3.16/Dockerfile (L91-L92)
Replaces default auth plugin verdaccio-htpasswd@10.x by verdaccio-htpasswd@11.x which is being used in verdaccio 6.x (almost identical)
Apply backward compabiity
Reduces maintenance (monorepo plugin can be removed)
One more step to switch v6.x
Add Node.js 12 GH Action for check backward compatibility
* fix: avoid setting body for GET requests
When making a GET request to certain uplinks, such as https://registry.npmmirror.com, setting the body field can result in a 413 error. Previously, the code was setting the body field for all requests, including GET requests.
This commit fixes the issue by checking the request method and avoiding setting the body field for GET requests. This ensures that GET requests are not affected by the issue and can be made without error.
Fixes#3601
* add missing deps for run test locally
* test(up-storage): add unit test about uplink is npmmirror
Cause thers is a bug in `isObject` function from `@verdaccio/core`, when `options.json` is `true`
GET request body will be string 'true', some uplinks might return 413 status code such as
https://registry.npmmirror.comfix#3601
* chore(deps): update @verdaccio/core
---------
Co-authored-by: Juan Picado <juanpicado19@gmail.com>
Co-authored-by: botao <botao@tal.com>
chore: clean up comments
remove commitlint
update deps
add new tests
test
separate ci
test
test
test
test
test
test
chore: add preprelase
test
test
test
test
test
chore: update deps
Update release-snapshot.yml
Update .npmignore
test
chore: remove @verdaccio/commons-api dep
chore: cleanup
remove normalizeContributors
remove validateMetadata
fix test
clean up getLocalRegistryTarballUri
Update store.spec.ts
clean up convertDistRemoteToLocalTarballUrls
chore: update libraries
reuse getPublic url
clean up
Update jest.config.js
Update jest.config.js
update nvmrc
add tests
* fix: get header by quality priority value
* chore: disable some workflows
* chore: add more tests
* chore: remove some duplicated testss
* chore: return right content type haders
* fix: add missing fields to abbreviated metadata
The abbreviated metadata should include the cpu, os, and peerDependenciesMeta fields
* chore: update types
Co-authored-by: Juan Picado <juanpicado19@gmail.com>
* Add a config item to web,let the developer can select whether enable the html cache
* Add a config item to web,let the developer can select whether enable the html cache
* chore: move check close to other configuration
* chore: update configuration files to suggest new option on web
* chore: format fix
Co-authored-by: fengdi <fengdi@bbktel.com>
Co-authored-by: Juan Picado <juanpicado19@gmail.com>
* pass `logs.colors` as `prettyOptions.colorize`
* `prettyPrintOptions` defaults is no concern of `createLogger`
* call it `colors` not to confuse with `pinoPretty.colorize`
* fix hardcoded `true` for `options.colors`
* Support `VERDACCIO_LOGGER_COLORS` overriding env-var
* Update docs for `VERDACCIO_LOGGER_COLORS`
* docs for `VERDACCIO_LOGGER_COLORS`
* docs for `VERDACCIO_LOGGER_COLORS`
* `.isTTY` from `stdout` not `stdin`
both work, but I want to ask if I emit to TTY, not if I consume from TTY.
* .md format
* format
* more format guesses
* declare `PrettyOptionsExtended.colors`
* lint
* docs: `EXPERIMENTAL__` prefix
* logger.ts - prefix `EXPERIMENTAL__`
* Update env.variables.md
* env.variables.md - remove double `_`
* Update logger.ts
* logger.ts - remove double `_`, fix boolean parsing
* env.variables.md - explain boolean parsing
* chore: format
* chore: add format, improve logic
Co-authored-by: Juan Picado <juanpicado19@gmail.com>
* WIP: port PR#2199 to master into 5.x
* port PR#2199 to master to 5.x - env.variables.md
* port PR#2199 to master to 5.x - config.spec
* Update config.spec.ts
* Update config.spec.ts
* fix format
Co-authored-by: Juan Picado <juanpicado19@gmail.com>
* fix: publish with deprecated field by @Jiasm
When publish with deprecated field in `package.json`, that will make all old versions miss.
Examples:
I have package@1.0.0 and package@1.0.1.
When `npm deprecate package@1.0.0 "xxx"`, Verdaccio will recived:
```json
{
"name": "module_name",
"version": {
"1.0.0": {
"deprecated": "xxx"
},
"1.0.1": {}
}
}
```
⬆️ This make sense
But then publish new version with @1.0.2.
Verdaccio will recived:
```json
{
"name": "module_name",
"version": {
"1.0.2": {
"deprecated": "xxx" // if we set this field in package.json
},
}
}
```
and that metadata will override package.json, make old version miss.
migrate from #2766
* remove spaces
* fix: ignore empty package case
* fix: cover normal unpublish case
* refactor: Optimize check logic for lazy execution
* test: upgrade Jest Snapshot
* fix: set storage.getPackage `uplinksLook: false`.
* feat: use `_attachments` to distinguish deprecate
* test: rollback test snapshots
* test: rollback jest snapshots
* test: publish new version with deprecate field
* test: remove space
* chore: enable pnp yarn
* chore: ignore pnp
* fix type issues on run eslint
* add missing dependency and fix some errors
* fix most of the errors
some were just disabled, already fixed in master
* add missing jest-config
* update jest@26 align with other deps
* add missing @babel/register
* clean up
* use yarn node
* use yarn node on release
* chore: add husky 6
* chore: add husky 6
* chore: lint-stage
* chore: test
* chore: add hook git
* chore: test
* chore: test
* update deps
* chore: fix commit lint
* fix docker run
* update git ignore
* feat: tarball url redirect
* fix: handle uplinks
* feat: allow function for config.tarball_url_redirect
* fix: hasLocalTarball was calling localStream,abort when already aborted
* chore: simplify localStream null check in hasLocalTarball
As requested in PR feedback.
* chore: fix sonarcloud code smell on test
the variable `credentials` was already declared before the tarball url tests.
* fix: move tarball_url_redirect to experiments
Co-authored-by: Gord Lea <johlea@cisco.com>
Co-authored-by: Gord Lea <jgordonlea@gmail.com>
# Number of days of inactivity before an issue becomes stale
daysUntilStale:15
# Number of days of inactivity before a stale issue is closed
daysUntilClose:10
# Issues with these labels will never be considered stale
exemptLabels:
- dev:high priority
- topic:feature request
- issue:need verification
- issue:bug
- dev:discuss
# Label to use when marking an issue as stale
staleLabel: issue:wontfix
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment:>
Hi pal 👋🏼!
This issue has gone quiet 😶.
We get a lot of issues, so we currently close issues after 25 days of inactivity. It’s been at least 15 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add/suggest the label "discuss" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out [https://github.com/verdaccio/contributing](https://github.com/verdaccio/contributing) for more information about opening PRs, triaging issues, and contributing!
Thanks for being a part of the Verdaccio community! 💘
# Comment to post when closing a stale issue. Set to `false` to disable
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at verdaccio.npm@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
> ⚠️ If you intend to file a PR with a new feature, please use the 5.x branch for it 🥰 . master branch is available only for **bug fixing** and dependencies updates.
We are happy that you wish to contribute to this project. For that reason, we
**Please read this document carefully. It will help maintainers and readers
in solving your issue(s), evaluating your feature request, etc.**
## Development
Development guides can be found on the [wiki](https://github.com/verdaccio/verdaccio/wiki):
* [Building the project](https://github.com/verdaccio/verdaccio/wiki/Build-Source-Code)
* [Running, debugging, and testing](https://github.com/verdaccio/verdaccio/wiki/Running-and-Debugging-tests)
## Reporting Bugs
We welcome clear, detailed bug reports.
**Bugs are considered features that are not working as described in
documentation.**
If you've found a bug in Verdaccio **that isn't a security risk**, please file
a report in our [issue tracker](https://github.com/verdaccio/verdaccio/issues).
**NOTE: Verdaccio still does not support all npm commands. Some were not
considered important and others have not been requested yet.**
### Issue Search
Search to see if it has already been reported via
the issue search.
Additionally, we have labelled questions for easy follow-up as [questions](https://github.com/verdaccio/verdaccio/labels/question).
If so, up-vote it (using GitHub reactions) or add additional helpful details to
the existing issue to show that it's affecting multiple people.
### Check Website For Solution
Some of the most popular topics can be found in our website(http://www.verdaccio.org/docs/en/installation.html)
### Chat
Questions can be asked via [Discord](http://chat.verdaccio.org/)
**Please use the `#questions#` and `#development` channels.**
### Check If It's Been Fixed
Check if the issue has been fixed — try to reproduce it using the latest
`master` or development branch in the repository.
## Request Features
New feature requests are welcome. Analyse whether the idea fits within scope of
the project. Then, detail your request, ensuring context and use case is provided.
**Please provide:**
* A detailed description the advantages of your request
* Whether or not it's compatible with `npm` and `yarn`
* A potential implementation or design
* Whatever else you have in your mind 🤓
### Submitting a Pull Request
The following are the steps you should follow when creating a pull request.
Subsequent pull requests only need to follow step 3 and beyond.
1. Fork the repository on GitHub
2. Clone the forked repository to your machine
3. Make your changes and commit them to your local repository
4. Rebase and push your commits to your GitHub remote fork/repository
5. Issue a Pull Request to the official repository
6. Your Pull Request is reviewed by a committer and merged into the repository
**NOTE**: While there are other ways to accomplish the steps using other tools,
the examples here will assume most actions will be performed via `git` on
command line.
For more information on maintaining a fork, please see the GitHub Help article
titled [Fork a Repo](https://help.github.com/articles/fork-a-repo/), and
information on [rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing).
### Make Changes and Commit
#### Before Commit
Before committing, **you must ensure there are no linting errors and
all tests pass.**
To do this, run all tests (including e2e):
```bash
yarn test:all
```
Then, and only then, you can create your pull request.
#### Commit Guidelines
We follow the [conventional commit messages](https://conventionalcommits.org/)
convention in order to automate CHANGELOG generation and to automate
semantic versioning.
For example:
*`feat: A new feature`
*`fix: A bug fix`
A commit of the type feat introduces a new feature to the codebase
(this correlates with MINOR in semantic versioning).
e.g.:
```
feat: xxxxxxxxxx
```
A commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
e.g.:
```
fix: xxxxxxxxxx
```
Commits types such as as `docs:`,`style:`,`refactor:`,`perf:`,`test:`
and `chore:` are valid but have no effect on versioning. **It would be great if you use them.**
All commits message are going to be validated when they are created using husky hooks.
**PRs that do not follow the commit message guidelines will not be merged.**
## Update Tests
**Any change in source code must include test updates**.
If you need help with how testing works, please [refer to the following guide](https://github.com/verdaccio/verdaccio/wiki/Running-and-Debugging-tests).
**If you are introducing new features, you MUST include new tests. PRs for
features without tests will not be merged.**
Things excluded from tests:
* Documentation
* Website
* Build
* Deployment
* Assets
* Flow types
## Develop Plugins
Plugins are add-ons that extend the functionality of the application.
If you want to develop your own plugin:
1. Check whether there is a legacy Sinopia plugin for the feature that you need
via [npmjs](https://www.npmjs.com/search?q=sinopia)
2. Keep in mind the [life-cycle to load a plugin](https://verdaccio.org/docs/en/dev-plugins)
3. You are free to host your plugin in your repository or ours (just ask)
4. Provide a detailed description of your plugin to help users understand it
Are you still using **Verdaccio 4**?. Check the [migration guide](https://verdaccio.org/blog/2021/04/14/verdaccio-5-migration-guide).
## Donations
Verdaccio is run by **volunteers**; nobody is working full-time on it. If you find this project to be useful and would like to support its development, consider making a donation - **your logo might end up in this readme.** 😉
**[Donate](https://github.com/sponsors/verdaccio)** 💵👍🏻 starting from _$1/month_ or just one single contribution.
## What does Verdaccio do for me?
### Use private packages
If you want to use all benefits of npm package system in your company without sending all code to the public, and use your private packages just as easy as public ones.
### Cache npmjs.org registry
If you have more than one server you want to install packages on, you might want to use this to decrease latency
(presumably "slow" npmjs.org will be connected to only once per package/version) and provide limited failover (if npmjs.org is down, we might still find something useful in the cache) or avoid issues like _[How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)_, _[Many packages suddenly disappeared](https://github.com/npm/registry-issue-archive/issues/255)_ or _[Registry returns 404 for a package I have installed before](https://github.com/npm/registry-issue-archive/issues/329)_.
### Link multiple registries
If you use multiples registries in your organization and need to fetch packages from multiple sources in one single project you might take advance of the uplinks feature with Verdaccio, chaining multiple registries and fetching from one single endpoint.
### Override public packages
If you want to use a modified version of some 3rd-party package (for example, you found a bug, but maintainer didn't accept pull request yet), you can publish your version locally under the same name. See in detail [here](https://verdaccio.org/docs/en/best#override-public-packages).
### E2E Testing
Verdaccio has proved to be a lightweight registry that can be
booted in a couple of seconds, fast enough for any CI. Many open source projects use verdaccio for end to end testing, to mention some examples, **create-react-app**, **mozilla neutrino**, **pnpm**, **storybook**, **alfresco** or **eclipse theia**. You can read more in dedicated article to E2E in our blog.
## Talks
### **Node.js Dependency Confusion Attacks & Vulnerabilities in Go Binaries**.
[RSVP](https://www.meetup.com/es-ES/devseccon-germany/events/276990087) to join the talk.
You might want to check out as well our previous talks:
- [**OpenJS World 2020** about \*Cover your Projects with a Multi purpose Lightweight Node.js Registry - **Juan Picado\***](https://www.youtube.com/watch?v=oVCjDWeehAQ)
- [ViennaJS Meetup - Introduction to Verdaccio by **Priscila Olivera** and **Juan Picado**](https://www.youtube.com/watch?v=hDIFKzmoCa)
- [Open Source? trivago - Verdaccio (**Ayush** and **Juan Picado**) January 2020](https://www.youtube.com/watch?v=A5CWxJC9xzc)
- [GitNation Open Source Stage - How we have built a Node.js Registry with React - **Juan Picado** December 2019](https://www.youtube.com/watch?v=gpjC8Qp9B9A)
- [Verdaccio - A lightweight Private Proxy Registry built in Node.js | **Juan Picado** at The Destro Dev Show](https://www.youtube.com/watch?reload=9&v=P_hxy7W-IL4&ab_channel=TheDestroDevShow)
## Get Started
Run in your terminal
```bash
verdaccio
```
You would need set some npm configuration, this is optional.
```bash
$ npm set registry http://localhost:4873/
```
For one-off commands or to avoid setting the registry globally:
```bash
NPM_CONFIG_REGISTRY=http://localhost:4873 npm i
```
Now you can navigate to [http://localhost:4873/](http://localhost:4873/) where your local packages will be listed and can be searched.
> Warning: Verdaccio [does not currently support PM2's cluster mode](https://github.com/verdaccio/verdaccio/issues/1301#issuecomment-489302298), running it with cluster mode may cause unknown behavior.
## Publishing
#### 1. create a user and log in
```bash
npm adduser --registry http://localhost:4873
```
> if you use HTTPS, add an appropriate CA information ("null" means get CA list from OS)
```bash
$ npm set ca null
```
#### 2. publish your package
```bash
npm publish --registry http://localhost:4873
```
This will prompt you for user credentials which will be saved on the `verdaccio` server.
## Docker
Below are the most commonly needed information,
every aspect of Docker and verdaccio is [documented separately](https://www.verdaccio.org/docs/en/docker.html)
```
docker pull verdaccio/verdaccio
```
Available as [tags](https://hub.docker.com/r/verdaccio/verdaccio/tags/).
```
docker pull verdaccio/verdaccio:5.x-next
```
### Running verdaccio using Docker
To run the docker container:
```bash
docker run -it --rm --name verdaccio -p 4873:4873 verdaccio/verdaccio
```
Docker examples are available [in this repository](https://github.com/verdaccio/docker-examples).
## Compatibility
Verdaccio aims to support all features of a standard npm client that make sense to support in private repository. Unfortunately, it isn't always possible.
If you want to report a security vulnerability, please follow the steps which we have defined for you in our [security policy](https://github.com/verdaccio/verdaccio/security/policy).
- [Amazon Encryption SDK for Javascript](https://github.com/aws/aws-encryption-sdk-javascript)
🤓 Don't be shy, you also can be in [the list](https://github.com/verdaccio/website/blob/master/docs/who-is-using.md).
## Open Collective Sponsors
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [[Become a sponsor](https://opencollective.com/verdaccio#sponsor)]
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.
The following table describes the versions of this project that are currently supported with security updates:
| Version | Supported |
| ------- | ------------------ |
| 2.x | :x: |
| 3.x | :x: |
| 4.x | :white_check_mark: (until 1st July 2021) |
| 5.x | :white_check_mark: |
## Responsible disclosure security policy
A responsible disclosure policy helps protect users of the project from publicly disclosed security vulnerabilities without a fix by employing a process where vulnerabilities are first triaged in a private manner, and only publicly disclosed after a reasonable time period that allows patching the vulnerability and provides an upgrade path for users.
When contacting us directly via email, we will do our best efforts to respond in a reasonable time to resolve the issue. When contacting a security program their disclosure policy will provide details on timeframe, processes and paid bounties.
We kindly ask you to refrain from malicious acts that put our users, the project, or any of the project’s team members at risk.
## Reporting a security issue
> Please do not use the provided email address to report issues which are not related to security vulnerabilities
At Verdaccio, we consider the security of our systems a top priority. But no matter how much effort we put into system security, there can still be vulnerabilities present.
If you discover a security vulnerability, please use one of the following means of communications to report it to us:
* Report the security issue to the Node.js Security WG through the [HackerOne program](https://hackerone.com/nodejs-ecosystem) for ecosystem modules on npm, or to [Snyk Security Team](https://snyk.io/vulnerability-disclosure). They will help triage the security issue and work with all involved parties to remediate and release a fix.
Note that time-frame and processes are subject to each program’s own policy.
* Report the security issue to the project maintainers directly at verdaccio@pm.me. If the report contains highly sensitive information, please be advised to encrypt your findings using our [PGP key](https://verdaccio.nyc3.digitaloceanspaces.com/gpg/publickey.verdaccio@pm.me.asc) which is also available in this document.
Your efforts to responsibly disclose your findings are sincerely appreciated and will be taken into account to acknowledge your contributions.
## PGP key
The following is this project’s PGP key which should be used to encrypt any sensitive information shared on unsecured medium such as e-mails:
<gid="Group-2-Copy"transform="translate(81.200000, 0.400000)"fill="#405236"font-family="OpenSansLight-Italic, Open Sans"font-size="42.4"font-style="italic"font-weight="300">
<gid="Group-2-Copy"transform="translate(81.200000, 0.400000)"fill="#405236"font-family="OpenSansLight-Italic, Open Sans"font-size="42.4"font-style="italic"font-weight="300">
<gid="Textmarke"transform="translate(28.400000, 77.000000)"fill="#405236"font-family="OpenSansLight-Italic, Open Sans"font-size="10"font-style="italic"font-weight="300">
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.