The script assumes that the name of the remote is `origin`, but this
is not the case if the user has set `clone.defaultRemoteName` to
another value in the ~/.gitconfig (or elsewhere in the configuration).
Adding `-o origin` ensures that the remote will be called `origin`
regardless of the `clone.defaultRemoteName` setting.
Per PR #3341:
- The minimum Git version this should work with is v1.7.10. (This is not
documented in the repo itself; it's just an implicit requirement.)
- The `--origin` option was added to `git clone` in commit 98a4fef3f2 which
was released in v1.2.5. From the diff of that commit, the `-o` option was
already available at that time. So this easily satisfies the above.
- A comment in #3341 indicates that `-o` was added in v1.1.0. I've not
verified this, but we probably don't need to track that down since by the
above we're already well within requirements.
This comprehensive guide helps GitHub Copilot better understand and navigate the nvm codebase by providing:
- Complete architecture explanation of nvm's POSIX-compliant design across multiple shells
- Detailed mapping of top-level commands to internal functions (install, use, ls, alias, etc.)
- Comprehensive testing infrastructure guide using urchin framework
- Shell environment setup for bash, zsh, dash, sh, and ksh
- CI environment details for GitHub Actions and Travis CI
- shellcheck setup and usage guidelines
- Development best practices for POSIX compliance and multi-shell compatibility
- Windows support via WSL2, Cygwin, and Git Bash
- Complete internal function categorization and debugging techniques
The documentation covers all aspects of the codebase to enable more accurate AI assistance when working with nvm's complex shell script architecture.
New Stuff
- `install.sh`: add `$ZDOTDIR` to zsh search (#3458)
Fixes
- `reinstall-packages`: do not reinstall corepack (#3544)
- avoid bash-specific syntax (#3499)
- `install-latest-npm`: npm v11 is out
- `nvm_install_latest_npm`: avoid unbound variable (#3447)
- give a more helpful message when `lts` alias is mistakenly used (#3441)
- `nvm ls`, `nvm alias`, `nvm install`: error when an LTS name is invalid
- `nvm_normalize_lts`: error when an LTS name is not lowercase (#3417)
Documentation
- [readme] update link
- [readme] fix `--no-use` example (#3479)
- [readme] update copyright notice (#3507)
- [readme] note zsh-nvm's AUTO_USE option (#2670)
- [readme] add note about reloading zshrc after editing (#3052)
- [readme] Update shell profile file install notes (#2241)
- [readme] add docker tips (#2318)
- [readme] remove `avn` from readme (#3469)
- [readme] fnm -> nvm.fish (#2541)
Refactors
- prefer `case` over if/else chains
- combine `sed -e` invocations/arguments
Tests
- `nvm exec`/`nvm run`: add `--silent` tests (#1259)
- [actions] release test needs git tags
- migrate `installation_iojs` test suite to GitHub Actions (#3476)
- Migrate slow test suite from Travis CI (#3470)
- temporarily skip this failing travis test to unblock progress
- [actions] TOC: use latest LTS node
- `install.sh`: clean up `nvm_detect_profile` tests
- `nvm_detect_profile`: refactor (#3467)
- run urchin tests on pull requests (#3466)
- update mocks
- ensure that unit tests use only mocked LTS names
- [actions] use `node/install` instead of `node/run`
Meta
- disable blank issues
- update issue template
- add DCO (#3456)
- Rename .github/ISSUE_TEMPLATE.md to .github/ISSUE_TEMPLATE/ISSUE_TEMPLATE.md (#3454)
We take the security of **nvm** very seriously. If you believe you’ve found a security vulnerability, please inform us responsibly through coordinated disclosure.
### How to Report
> **Do not** report security vulnerabilities through public GitHub issues, discussions, or social media.
Instead, please use one of these secure channels:
1.**GitHub Security Advisories**
Use the **Report a vulnerability** button in the Security tab of the [nvm-sh/nvm repository](https://github.com/nvm-sh/nvm).
2.**Email**
Follow the posted [Security Policy](https://github.com/nvm-sh/nvm/security/policy).
### What to Include
**Required Information:**
- Brief description of the vulnerability type
- Affected version(s) and components
- Steps to reproduce the issue
- Impact assessment (what an attacker could achieve)
**Helpful Additional Details:**
- Full paths of affected scripts or files
- Specific commit or branch where the issue exists
- Required configuration to reproduce
- Proof-of-concept code (if available)
- Suggested mitigation or fix
## Our Response Process
**Timeline Commitments:**
- **Initial acknowledgment**: Within 24 hours
- **Detailed response**: Within 3 business days
- **Status updates**: Every 7 days until resolved
- **Resolution target**: 90 days for most issues
**What We’ll Do:**
1. Acknowledge your report and assign a tracking ID
2. Assess the vulnerability and determine severity
3. Develop and test a fix
4. Coordinate disclosure timeline with you
5. Release a security update and publish an advisory and CVE
6. Credit you in our security advisory (if desired)
## Disclosure Policy
- **Coordinated disclosure**: We’ll work with you on timing
- **Typical timeline**: 90 days from report to public disclosure
- **Early disclosure**: If actively exploited
- **Delayed disclosure**: For complex issues
## Scope
**In Scope:**
- **nvm** project (all supported versions)
- Installation and update scripts (`install.sh`, `nvm.sh`)
- Official documentation and CI/CD integrations
- Dependencies with direct security implications
**Out of Scope:**
- Third-party forks or mirrors
- Platform-specific installs outside core scripts
- Social engineering or physical attacks
- Theoretical vulnerabilities without practical exploitation
## Security Measures
**Our Commitments:**
- Regular vulnerability scanning via GitHub Actions
- Automated security checks in CI/CD pipelines
- Secure scripting practices and mandatory code review
- Prompt patch releases for critical issues
**User Responsibilities:**
- Keep **nvm** updated
- Verify script downloads via PGP signatures
- Follow secure configuration guidelines for shell environments
## Legal Safe Harbor
**We will NOT:**
- Initiate legal action
- Contact law enforcement
- Suspend or terminate your access
**You must:**
- Only test against your own installations
- Not access, modify, or delete user data
- Not degrade service availability
- Not publicly disclose before coordinated disclosure
- Act in good faith
## Recognition
- **Advisory Credits**: Credit in GitHub Security Advisories (unless anonymous)
## Security Updates
**Stay Informed:**
- Subscribe to GitHub releases for **nvm**
- Enable GitHub Security Advisory notifications
**Update Process:**
- Patch releases (e.g., v0.40.3 → v0.40.4)
- Out-of-band releases for critical issues
- Advisories via GitHub Security Advisories
## Contact Information
- **Security reports**: Security tab of [nvm-sh/nvm](https://github.com/nvm-sh/nvm/security)
- **General inquiries**: GitHub Discussions or Issues
<!-- Thank you for being interested in nvm! Please help us by filling out the following form if you‘re having trouble. If you have a feature request, or some other question, please feel free to clear out the form. Thanks! -->
Please email [@ljharb](https://github.com/ljharb) or see https://tidelift.com/security if you have a potential security vulnerability to report.
Please file a private vulnerability report via GitHub, email [@ljharb](https://github.com/ljharb), or see https://tidelift.com/security if you have a potential security vulnerability to report.
## OpenSSF CII Best Practices
@@ -12,16 +12,17 @@ There are three “tiers”: passing, silver, and gold.
We meet 100% of the “passing” criteria.
### Silver
We meet 95% of the “silver” criteria. The gaps are as follows:
- we do not have a DCO or a CLA process for contributions.
- because we only have one maintainer, the project has no way to continue if that maintainer stops being active.
- we do not currently document “what the user can and cannot expect in terms of security” for our project. This is planned to be completed in 2023.
We meet 100% of the “silver” criteria.
### Gold
We meet 65% of the “gold” criteria. The gaps are as follows:
-we do not yet have the “silver” badge; see all the gaps above.
We meet 78% of the “gold” criteria. The gaps are as follows:
-because we only have one maintainer, the project has no way to continue if that maintainer stops being active.
- We do not include a copyright or license statement in each source file. Efforts are underway to change this archaic practice into a suggestion instead of a hard requirement.
## Threat Model
See [THREAT_MODEL.md](./THREAT_MODEL.md).
See [THREAT_MODEL.md](.github/THREAT_MODEL.md).
## Incident Response Plan
Please see our [Incident Response Plan](.github/INCIDENT_RESPONSE_PLAN.md).
This document provides guidance for GitHub Copilot when working with the Node Version Manager (nvm) codebase.
## Overview
nvm is a version manager for Node.js, implemented as a POSIX-compliant function that works across multiple shells (sh, dash, bash, ksh, zsh). The codebase is primarily written in shell script and emphasizes portability and compatibility.
### Core Architecture
- **Main script**: `nvm.sh` - Contains all core functionality and the main `nvm()` function
1.**Quoting**: Always quote variables: `"${VAR}"` instead of `$VAR`
2.**POSIX compliance**: Avoid bash-specific features in portable sections
3.**Array usage**: Use `set --` for positional parameters instead of arrays, which are not supported in POSIX
4.**Local variables**: Declared with `local FOO` and then initialized on the next line (the latter is for ksh support)
## Development Best Practices
### Code Style
- Use 2-space indentation
- Follow POSIX shell guidelines for portability
- Prefix internal functions with `nvm_`
- Use `nvm_echo` instead of `echo` for output
- Use `nvm_err` for error messages
### Compatibility
- Test changes across all supported shells
- Avoid bash-specific features in core functionality
- Use `nvm_is_zsh` to check when zsh-specific behavior is needed
- Mock external dependencies in tests
### Performance
- Cache expensive operations (like remote version lists)
- Use local variables to avoid scope pollution
- Minimize subprocess calls where possible
- Implement lazy loading for optional features
### Debugging
- Use `nvm debug` command for environment information
- Enable verbose output with `set -x` during development
- Test with `NVM_DEBUG=1` environment variable
- Check `$NVM_DIR/.cache` for cached data issues
## Common Gotchas
1.**PATH modification**: nvm modifies PATH extensively; be careful with restoration
2.**Shell sourcing**: nvm must be sourced, not executed as a script
3.**Version resolution**: Aliases, partial versions, and special keywords interact complexly
4.**Platform differences**: Handle differences between Linux, macOS, and other Unix systems
5.**Network dependencies**: Many operations require internet access for version lists
6.**Concurrent access**: Multiple shells can conflict when installing versions simultaneously
## Windows Support
nvm works on Windows via several compatibility layers:
### WSL2 (Windows Subsystem for Linux)
- Full nvm functionality available
- **Important**: Ensure you're using WSL2, not WSL1 - see [Microsoft's WSL2 installation guide](https://docs.microsoft.com/en-us/windows/wsl/install) for up-to-date instructions
- Install Ubuntu or other Linux distribution from Microsoft Store
- Follow Linux installation instructions within WSL2
### Cygwin
- POSIX-compatible environment for Windows
- Download Cygwin from [cygwin.com](https://www.cygwin.com/install.html) and run the installer
- During installation, include these packages: bash, curl, git, tar, and wget
- May require additional PATH configuration
### Git Bash (MSYS2)
- Comes with Git for Windows
- Limited functionality compared to full Linux environment
- Some features may not work due to path translation issues, including:
- Binary extraction paths may be incorrectly translated
- Symlink creation may fail
- Some shell-specific features may behave differently
- File permissions handling differs from Unix systems
### Setup Instructions for Windows
#### WSL2 (recommended)
1. Install WSL2 using the official Microsoft guide: https://docs.microsoft.com/en-us/windows/wsl/install
2. Install Ubuntu or preferred Linux distribution from Microsoft Store
3. Follow standard Linux installation within WSL2
#### Git Bash
1. Install Git for Windows (includes Git Bash) from https://git-scm.com/download/win
2. Open Git Bash terminal
3. Run nvm installation script
#### Cygwin
1. Download and install Cygwin from https://www.cygwin.com/install.html
2. Include bash, curl, git, tar, and wget packages during installation
3. Run nvm installation in Cygwin terminal
This guide should help GitHub Copilot understand the nvm codebase structure, testing procedures, and development environment setup requirements.
@@ -113,3 +113,11 @@ Co-authored-by: Name Here <email@here>
# Where can I ask for help?
If you have any questions, please contact [@LJHarb](mailto:ljharb@gmail.com).
# Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
- The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
- The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
- The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
- I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
- [Installing in Docker for CICD-Jobs](#installing-in-docker-for-cicd-jobs)
- [Troubleshooting on Linux](#troubleshooting-on-linux)
- [Troubleshooting on macOS](#troubleshooting-on-macos)
- [Ansible](#ansible)
@@ -102,13 +104,13 @@ nvm is a version manager for [node.js](https://nodejs.org/en/), designed to be i
To **install** or **update** nvm, you should run the [install script][2]. To do that, you may either download and run the script manually, or use the following cURL or Wget command:
Running either of the above commands downloads a script and runs it. The script clones the nvm repository to `~/.nvm`, and attempts to add the source lines from the snippet below to the correct profile file (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`).
Running either of the above commands downloads a script and runs it. The script clones the nvm repository to `~/.nvm`, and attempts to add the source lines from the snippet below to the correct profile file (`~/.bashrc`, `~/.bash_profile`, `~/.zshrc`, or`~/.profile`). If you find the install script is updating the wrong profile file, set the `$PROFILE` env var to the profile file’s path, and then rerun the installation script.
[ -s "$NVM_DIR/nvm.sh"]&&\."$NVM_DIR/nvm.sh" --no-use # This loads nvm, without auto-using the default version
```
- You can customize the install source, directory, profile, and version using the `NVM_SOURCE`, `NVM_DIR`, `PROFILE`, and `NODE_VERSION` variables.
Eg: `curl ... | NVM_DIR="path/to/nvm"`. Ensure that the `NVM_DIR` does not contain a trailing slash.
- The installer can use `git`, `curl`, or `wget` to download `nvm`, whichever is available.
- You can instruct the installer to not edit your shell config (for example if you already get completions via a [zsh nvm plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/nvm)) by setting `PROFILE=/dev/null` before running the `install.sh` script. Here's an example one-line command to do that: `PROFILE=/dev/null bash -c 'curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash'`
- You can instruct the installer to not edit your shell config (for example if you already get completions via a [zsh nvm plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/nvm)) by setting `PROFILE=/dev/null` before running the `install.sh` script. Here's an example one-line command to do that: `PROFILE=/dev/null bash -c 'curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash'`
#### Installing in Docker
When invoking bash as a non-interactive shell, like in a Docker container, none of the regular profile files are sourced. In order to use `nvm`, `node`, and `npm` like normal, you can instead specify the special `BASH_ENV` variable, which bash sources when invoked non-interactively.
```Dockerfile
# Use bash for the shell
SHELL["/bin/bash","-o","pipefail","-c"]
# Create a script file sourced by both interactive and non-interactive bash shells
ENV BASH_ENV /home/user/.bash_env
RUN touch "${BASH_ENV}"
RUNecho'. "${BASH_ENV}"' >> ~/.bashrc
# Download and install nvm
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh |PROFILE="${BASH_ENV}" bash
RUNecho node > .nvmrc
RUN nvm install
```
##### Installing in Docker for CICD-Jobs
More robust, works in CI/CD-Jobs. Can be run in interactive and non-interactive containers.
See https://github.com/nvm-sh/nvm/issues/3531.
```Dockerfile
FROMubuntu:latest
ARGNODE_VERSION=20
# install curl
RUN apt update && apt install curl -y
# install nvm
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
# set env
ENVNVM_DIR=/root/.nvm
# install node
RUN bash -c "source $NVM_DIR/nvm.sh && nvm install $NODE_VERSION"
@@ -207,7 +289,7 @@ If you're running a system without prepackaged binary available, which means you
- [bass](https://github.com/edc/bass) allows you to use utilities written for Bash in fish shell
- [fast-nvm-fish](https://github.com/brigand/fast-nvm-fish) only works with version numbers (not aliases) but doesn't significantly slow your shell startup
- [plugin-nvm](https://github.com/derekstavis/plugin-nvm) plugin for [Oh My Fish](https://github.com/oh-my-fish/oh-my-fish), which makes nvm and its completions available in fish shell
- [fnm](https://github.com/fisherman/fnm) - [fisherman](https://github.com/fisherman/fisherman)-based version manager for fish
- [nvm.fish](https://github.com/jorgebucaran/nvm.fish) - The Node.js version manager you'll adore, crafted just for Fish
- [fish-nvm](https://github.com/FabioAntunes/fish-nvm) - Wrapper around nvm for fish, delays sourcing nvm until it's actually used.
**Note:** We still have some problems with FreeBSD, because there is no official pre-built binary for FreeBSD, and building from source may need [patches](https://www.freshports.org/www/node/files/patch-deps_v8_src_base_platform_platform-posix.cc); see the issue ticket:
@@ -227,7 +309,7 @@ If you're running a system without prepackaged binary available, which means you
Homebrew installation is not supported. If you have issues with homebrew-installed `nvm`, please `brew uninstall` it, and install it using the instructions below, before filing an issue.
**Note:** If you're using `zsh` you can easily install `nvm` as a zsh plugin. Install [`zsh-nvm`](https://github.com/lukechilds/zsh-nvm) and run `nvm upgrade` to upgrade.
**Note:** If you're using `zsh` you can easily install `nvm` as a zsh plugin. Install [`zsh-nvm`](https://github.com/lukechilds/zsh-nvm) and run `nvm upgrade` to upgrade ([you can set](https://github.com/lukechilds/zsh-nvm#auto-use) `NVM_AUTO_USE=true` to have it automatically detect and use `.nvmrc` files).
**Note:** Git versions before v1.7 may face a problem of cloning `nvm` source from GitHub via https protocol, and there is also different behavior of git before v1.6, and git prior to [v1.17.10](https://github.com/git/git/commit/5a7d5b683f869d3e3884a89775241afa515da9e7) can not clone tags, so the minimum required git version is v1.7.10. If you are interested in the problem we mentioned here, please refer to GitHub's [HTTPS cloning errors](https://help.github.com/articles/https-cloning-errors/) article.
@@ -237,7 +319,7 @@ If you have `git` installed (requires git v1.7.10+):
1. clone this repo in the root of your user profile
-`cd ~/` from anywhere then `git clone https://github.com/nvm-sh/nvm.git .nvm`
1.`cd ~/.nvm` and check out the latest version with `git checkout v0.40.1`
1.`cd ~/.nvm` and check out the latest version with `git checkout v0.40.3`
1. activate `nvm` by sourcing it from your shell: `. ./nvm.sh`
Now add these lines to your `~/.bashrc`, `~/.profile`, or `~/.zshrc` file to have it automatically sourced upon login:
@@ -588,9 +670,7 @@ Run [`npx nvmrc`](https://npmjs.com/nvmrc) to validate an `.nvmrc` file. If that
### Deeper Shell Integration
You can use [`avn`](https://github.com/wbyoung/avn) to deeply integrate into your shell and automatically invoke `nvm`when changing directories. `avn` is **not** supported by the `nvm` maintainers. Please [report issues to the `avn` team](https://github.com/wbyoung/avn/issues/new).
You can also use [`nvshim`](https://github.com/iamogbz/nvshim) to shim the `node`, `npm`, and `npx` bins to automatically use the `nvm` config in the current directory. `nvshim` is **not** supported by the `nvm` maintainers. Please [report issues to the `nvshim` team](https://github.com/iamogbz/nvshim/issues/new).
You can use [`nvshim`](https://github.com/iamogbz/nvshim) to shim the `node`, `npm`, and `npx` bins to automatically use the `nvm`config in the current directory. `nvshim` is **not** supported by the `nvm` maintainers. Please [report issues to the `nvshim` team](https://github.com/iamogbz/nvshim/issues/new).
If you prefer a lighter-weight solution, the recipes below have been contributed by `nvm` users. They are **not** supported by the `nvm` maintainers. We are, however, accepting pull requests for more examples.
@@ -685,6 +765,8 @@ add-zsh-hook chpwd load-nvmrc
load-nvmrc
```
After saving the file, run `source ~/.zshrc` to reload the configuration with the latest changes made.
##### fish
This requires that you have [bass](https://github.com/edc/bass) installed.
_Note: Alpine 3.5 can only install NodeJS versions up to v6.9.5, Alpine 3.6 can only install versions up to v6.10.3, Alpine 3.7 installs versions up to v8.9.3, Alpine 3.8 installs versions up to v8.14.0, Alpine 3.9 installs versions up to v10.19.0, Alpine 3.10 installs versions up to v10.24.1, Alpine 3.11 installs versions up to v12.22.6, Alpine 3.12 installs versions up to v12.22.12, Alpine 3.13 & 3.14 install versions up to v14.20.0, Alpine 3.15 & 3.16 install versions up to v16.16.0 (**These are all versions on the main branch**). Alpine 3.5 - 3.12 required the package `python2` to build NodeJS, as they are older versions to build. Alpine 3.13+ requires `python3` to successfully build newer NodeJS versions, but you can use `python2` with Alpine 3.13+ if you need to build versions of node supported in Alpine 3.5 - 3.15, you just need to specify what version of NodeJS you need to install in the package install script._
@@ -952,9 +1034,9 @@ You have to make sure that the user directory name in `$HOME` and the user direc
To change the user directory and/or account name follow the instructions [here](https://support.apple.com/en-us/HT201548)
@@ -1012,7 +1094,7 @@ Here's what you will need to do:
If one of these broken versions is installed on your system, the above step will likely still succeed even if you didn't include the `--shared-zlib` flag.
However, later, when you attempt to `npm install` something using your old version of node.js, you will see `incorrect data check` errors.
If you want to avoid the possible hassle of dealing with this, include that flag.
For more details, see [this issue](https://github.com/nodejs/node/issues/39313) and [this comment](https://github.com/nodejs/node/issues/39313#issuecomment-90.40.176)
For more details, see [this issue](https://github.com/nodejs/node/issues/39313) and [this comment](https://github.com/nodejs/node/issues/39313#issuecomment-90.40.376)
- Exit back to your native shell.
@@ -1039,7 +1121,7 @@ Now you should be able to use node as usual.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:09 --:--:-- 0curl: (6) Could not resolve host: raw.githubusercontent.com
@@ -1074,7 +1156,7 @@ Currently, the sole maintainer is [@ljharb](https://github.com/ljharb) - more ma
## Project Support
Only the latest version (v0.40.1 at this time) is supported.
Only the latest version (v0.40.3 at this time) is supported.
## Enterprise Support
@@ -1088,6 +1170,5 @@ See [LICENSE.md](./LICENSE.md).
## Copyright notice
Copyright [OpenJS Foundation](https://openjsf.org) and `nvm` contributors. All rights reserved. The [OpenJS Foundation](https://openjsf.org) has registered trademarks and uses trademarks. For a list of trademarks of the [OpenJS Foundation](https://openjsf.org), please see our [Trademark Policy](https://trademark-policy.openjsf.org/) and [Trademark List](https://trademark-list.openjsf.org/). Node.js is a trademark of Joyent, Inc. and is used with its permission. Trademarks and logos not indicated on the [list of OpenJS Foundation trademarks](https://trademark-list.openjsf.org) are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
Copyright [OpenJS Foundation](https://openjsf.org) and `nvm` contributors. All rights reserved. The [OpenJS Foundation](https://openjsf.org) has registered trademarks and uses trademarks. For a list of trademarks of the [OpenJS Foundation](https://openjsf.org), please see our [Trademark Policy](https://trademark-policy.openjsf.org/) and [Trademark List](https://trademark-list.openjsf.org/). Trademarks and logos not indicated on the [list of OpenJS Foundation trademarks](https://trademark-list.openjsf.org) are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
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.
