@patternfly-java/charts 0.0.1 → 0.0.3

package/node/node_modules/npm/docs/content/using-npm/dependency-selectors.md

@@ -1,223 +0,0 @@
----
-title: Dependency Selector Syntax & Querying
-section: 7
-description: Dependency Selector Syntax & Querying
----
-
-### Description
-
-The [`npm query`](/commands/npm-query) command exposes a new dependency selector syntax (informed by & respecting many aspects of the [CSS Selectors 4 Spec](https://dev.w3.org/csswg/selectors4/#relational)) which:
-
-- Standardizes the shape of, & querying of, dependency graphs with a robust object model, metadata & selector syntax
-- Leverages existing, known language syntax & operators from CSS to make disparate package information broadly accessible
-- Unlocks the ability to answer complex, multi-faceted questions about dependencies, their relationships & associative metadata
-- Consolidates redundant logic of similar query commands in `npm` (ex. `npm fund`, `npm ls`, `npm outdated`, `npm audit` ...)
-
-### Dependency Selector Syntax
-
-#### Overview:
-
-- there is no "type" or "tag" selectors (ex. `div, h1, a`) as a dependency/target is the only type of `Node` that can be queried
-- the term "dependencies" is in reference to any `Node` found in a `tree` returned by `Arborist`
-
-#### Combinators
-
-- `>` direct descendant/child
-- ` ` any descendant/child
-- `~` sibling
-
-#### Selectors
-
-- `*` universal selector
-- `#<name>` dependency selector (equivalent to `[name="..."]`)
-- `#<name>@<version>` (equivalent to `[name=<name>]:semver(<version>)`)
-- `,` selector list delimiter
-- `.` dependency type selector
-- `:` pseudo selector
-
-#### Dependency Type Selectors
-
-- `.prod` dependency found in the `dependencies` section of `package.json`, or is a child of said dependency
-- `.dev` dependency found in the `devDependencies` section of `package.json`, or is a child of said dependency
-- `.optional` dependency found in the `optionalDependencies` section of `package.json`, or has `"optional": true` set in its entry in the `peerDependenciesMeta` section of `package.json`, or a child of said dependency
-- `.peer` dependency found in the `peerDependencies` section of `package.json`
-- `.workspace` dependency found in the [`workspaces`](https://docs.npmjs.com/cli/v8/using-npm/workspaces) section of `package.json`
-- `.bundled` dependency found in the `bundleDependencies` section of `package.json`, or is a child of said dependency
-
-#### Pseudo Selectors
-- [`:not(<selector>)`](https://developer.mozilla.org/en-US/docs/Web/CSS/:not)
-- [`:has(<selector>)`](https://developer.mozilla.org/en-US/docs/Web/CSS/:has)
-- [`:is(<selector list>)`](https://developer.mozilla.org/en-US/docs/Web/CSS/:is)
-- [`:root`](https://developer.mozilla.org/en-US/docs/Web/CSS/:root) matches the root node/dependency
-- [`:scope`](https://developer.mozilla.org/en-US/docs/Web/CSS/:scope) matches node/dependency it was queried against
-- [`:empty`](https://developer.mozilla.org/en-US/docs/Web/CSS/:empty) when a dependency has no dependencies
-- [`:private`](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#private) when a dependency is private
-- `:link` when a dependency is linked (for instance, workspaces or packages manually [`linked`](https://docs.npmjs.com/cli/v8/commands/npm-link)
-- `:deduped` when a dependency has been deduped (note that this does *not* always mean the dependency has been hoisted to the root of node_modules)
-- `:overridden` when a dependency has been overridden
-- `:extraneous` when a dependency exists but is not defined as a dependency of any node
-- `:invalid` when a dependency version is out of its ancestors specified range
-- `:missing` when a dependency is not found on disk
-- `:semver(<spec>, [selector], [function])` match a valid [`node-semver`](https://github.com/npm/node-semver) version or range to a selector
-- `:path(<path>)` [glob](https://www.npmjs.com/package/glob) matching based on dependencies path relative to the project
-- `:type(<type>)` [based on currently recognized types](https://github.com/npm/npm-package-arg#result-object)
-- `:outdated(<type>)` when a dependency is outdated
-- `:vuln(<selector>)` when a dependency has a known vulnerability
-
-##### `:semver(<spec>, [selector], [function])`
-
-The `:semver()` pseudo selector allows comparing fields from each node's `package.json` using [semver](https://github.com/npm/node-semver#readme) methods. It accepts up to 3 parameters, all but the first of which are optional.
-
-- `spec` a semver version or range
-- `selector` an attribute selector for each node (default `[version]`)
-- `function` a semver method to apply, one of: `satisfies`, `intersects`, `subset`, `gt`, `gte`, `gtr`, `lt`, `lte`, `ltr`, `eq`, `neq` or the special function `infer` (default `infer`)
-
-When the special `infer` function is used the `spec` and the actual value from the node are compared. If both are versions, according to `semver.valid()`, `eq` is used. If both values are ranges, according to `!semver.valid()`, `intersects` is used. If the values are mixed types `satisfies` is used.
-
-Some examples:
-
-- `:semver(^1.0.0)` returns every node that has a `version` satisfied by the provided range `^1.0.0`
-- `:semver(16.0.0, :attr(engines, [node]))` returns every node which has an `engines.node` property satisfying the version `16.0.0`
-- `:semver(1.0.0, [version], lt)` every node with a `version` less than `1.0.0`
-
-##### `:outdated(<type>)`
-
-The `:outdated` pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. The type parameter may be one of the following:
-
-- `any` (default) a version exists that is greater than the current one
-- `in-range` a version exists that is greater than the current one, and satisfies at least one if its parent's dependencies
-- `out-of-range` a version exists that is greater than the current one, does not satisfy at least one of its parent's dependencies
-- `major` a version exists that is a semver major greater than the current one
-- `minor` a version exists that is a semver minor greater than the current one
-- `patch` a version exists that is a semver patch greater than the current one
-
-In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. The following data can be found under the `queryContext` property of each node.
-
-- `versions` an array of every available version of the given node
-- `outdated.inRange` an array of objects, each with a `from` and `versions`, where `from` is the on-disk location of the node that depends on the current node and `versions` is an array of all available versions that satisfies that dependency. This is only populated if `:outdated(in-range)` is used.
-- `outdated.outOfRange` an array of objects, identical in shape to `inRange`, but where the `versions` array is every available version that does not satisfy the dependency. This is only populated if `:outdated(out-of-range)` is used.
-
-Some examples:
-
-- `:root > :outdated(major)` returns every direct dependency that has a new semver major release
-- `.prod:outdated(in-range)` returns production dependencies that have a new release that satisfies at least one of its parent's dependencies
-
-##### `:vuln`
-
-The `:vuln` pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability.  Only dependencies whose current version matches a vulnerability will be returned.  For example if you have `semver@7.6.0` in your tree, a vulnerability for `semver` which affects versions `<=6.3.1` will not match.
-
-You can also filter results by certain attributes in advisories.  Currently that includes `severity` and `cwe`.  Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified.
-
-In addition to the filtering performed by the pseudo selector, info about each relevant advisory will be added to the `queryContext` attribute of each node under the `advisories` attribute.
-
-Some examples:
-
-- `:root > .prod:vuln` returns direct production dependencies with any known vulnerability
-- `:vuln([severity=high])` returns only dependencies with a vulnerability with a `high` severity.
-- `:vuln([severity=high],[severity=moderate])` returns only dependencies with a vulnerability with a `high`  or `moderate` severity.
-- `:vuln([cwe=1333])` returns only dependencies with a vulnerability that includes CWE-1333 (ReDoS)
-
-#### [Attribute Selectors](https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors)
-
-The attribute selector evaluates the key/value pairs in `package.json` if they are `String`s.
-
-- `[]` attribute selector (ie. existence of attribute)
-- `[attribute=value]` attribute value is equivalent...
-- `[attribute~=value]` attribute value contains word...
-- `[attribute*=value]` attribute value contains string...
-- `[attribute|=value]` attribute value is equal to or starts with...
-- `[attribute^=value]` attribute value starts with...
-- `[attribute$=value]` attribute value ends with...
-
-#### `Array` & `Object` Attribute Selectors
-
-The generic `:attr()` pseudo selector standardizes a pattern which can be used for attribute selection of `Object`s, `Array`s or `Arrays` of `Object`s accessible via `Arborist`'s `Node.package` metadata. This allows for iterative attribute selection beyond top-level `String` evaluation. The last argument passed to `:attr()` must be an `attribute` selector or a nested `:attr()`. See examples below:
-
-#### `Objects`
-
-```css
-/* return dependencies that have a `scripts.test` containing `"tap"` */
-*:attr(scripts, [test~=tap])
-```
-
-#### Nested `Objects`
-
-Nested objects are expressed as sequential arguments to `:attr()`.
-
-```css
-/* return dependencies that have a testling config for opera browsers */
-*:attr(testling, browsers, [~=opera])
-```
-
-#### `Arrays`
-
-`Array`s specifically uses a special/reserved `.` character in place of a typical attribute name. `Arrays` also support exact `value` matching when a `String` is passed to the selector.
-
-##### Example of an `Array` Attribute Selection:
-```css
-/* removes the distinction between properties & arrays */
-/* ie. we'd have to check the property & iterate to match selection */
-*:attr([keywords^=react])
-*:attr(contributors, :attr([name~=Jordan]))
-```
-
-##### Example of an `Array` matching directly to a value:
-```css
-/* return dependencies that have the exact keyword "react" */
-/* this is equivalent to `*:keywords([value="react"])` */
-*:attr([keywords=react])
-```
-
-##### Example of an `Array` of `Object`s:
-```css
-/* returns */
-*:attr(contributors, [email=ruyadorno@github.com])
-```
-
-### Groups
-
-Dependency groups are defined by the package relationships to their ancestors (ie. the dependency types that are defined in `package.json`). This approach is user-centric as the ecosystem has been taught to think about dependencies in these groups first-and-foremost. Dependencies are allowed to be included in multiple groups (ex. a `prod` dependency may also be a `dev` dependency (in that it's also required by another `dev` dependency) & may also be `bundled` - a selector for that type of dependency would look like: `*.prod.dev.bundled`).
-
-- `.prod`
-- `.dev`
-- `.optional`
-- `.peer`
-- `.bundled`
-- `.workspace`
-
-Please note that currently `workspace` deps are always `prod` dependencies.  Additionally the `.root` dependency is also considered a `prod` dependency.
-
-### Programmatic Usage
-
-- `Arborist`'s `Node` Class has a `.querySelectorAll()` method
-  - this method will return a filtered, flattened dependency Arborist `Node` list based on a valid query selector
-
-```js
-const Arborist = require('@npmcli/arborist')
-const arb = new Arborist({})
-```
-
-```js
-// root-level
-arb.loadActual().then(async (tree) => {
-  // query all production dependencies
-  const results = await tree.querySelectorAll('.prod')
-  console.log(results)
-})
-```
-
-```js
-// iterative
-arb.loadActual().then(async (tree) => {
-  // query for the deduped version of react
-  const results = await tree.querySelectorAll('#react:not(:deduped)')
-  // query the deduped react for git deps
-  const deps = await results[0].querySelectorAll(':type(git)')
-  console.log(deps)
-})
-```
-
-## See Also
-
-* [npm query](/commands/npm-query)
-* [@npmcli/arborist](https://npm.im/@npmcli/arborist)

package/node/node_modules/npm/docs/content/using-npm/developers.md

@@ -1,247 +0,0 @@
----
-title: developers
-section: 7
-description: Developer Guide
----
-
-### Description
-
-So, you've decided to use npm to develop (and maybe publish/deploy)
-your project.
-
-Fantastic!
-
-There are a few things that you need to do above the simple steps
-that your users will do to install your program.
-
-### About These Documents
-
-These are man pages.  If you install npm, you should be able to
-then do `man npm-thing` to get the documentation on a particular
-topic, or `npm help thing` to see the same information.
-
-### What is a Package
-
-A package is:
-
-* a) a folder containing a program described by a package.json file
-* b) a gzipped tarball containing (a)
-* c) a url that resolves to (b)
-* d) a `<name>@<version>` that is published on the registry with (c)
-* e) a `<name>@<tag>` that points to (d)
-* f) a `<name>` that has a "latest" tag satisfying (e)
-* g) a `git` url that, when cloned, results in (a).
-
-Even if you never publish your package, you can still get a lot of
-benefits of using npm if you just want to write a node program (a), and
-perhaps if you also want to be able to easily install it elsewhere
-after packing it up into a tarball (b).
-
-Git urls can be of the form:
-
-```bash
-git://github.com/user/project.git#commit-ish
-git+ssh://user@hostname:project.git#commit-ish
-git+http://user@hostname/project/blah.git#commit-ish
-git+https://user@hostname/project/blah.git#commit-ish
-```
-
-The `commit-ish` can be any tag, sha, or branch which can be supplied as
-an argument to `git checkout`.  The default is whatever the repository uses
-as its default branch.
-
-### The package.json File
-
-You need to have a `package.json` file in the root of your project to do
-much of anything with npm.  That is basically the whole interface.
-
-See [`package.json`](/configuring-npm/package-json) for details about what
-goes in that file.  At the very least, you need:
-
-* name: This should be a string that identifies your project.  Please do
-  not use the name to specify that it runs on node, or is in JavaScript.
-  You can use the "engines" field to explicitly state the versions of node
-  (or whatever else) that your program requires, and it's pretty well
-  assumed that it's JavaScript.
-
-  It does not necessarily need to match your github repository name.
-
-  So, `node-foo` and `bar-js` are bad names.  `foo` or `bar` are better.
-
-* version: A semver-compatible version.
-
-* engines: Specify the versions of node (or whatever else) that your
-  program runs on.  The node API changes a lot, and there may be bugs or
-  new functionality that you depend on.  Be explicit.
-
-* author: Take some credit.
-
-* scripts: If you have a special compilation or installation script, then
-  you should put it in the `scripts` object.  You should definitely have at
-  least a basic smoke-test command as the "scripts.test" field.  See
-  [scripts](/using-npm/scripts).
-
-* main: If you have a single module that serves as the entry point to your
-  program (like what the "foo" package gives you at require("foo")), then
-  you need to specify that in the "main" field.
-
-* directories: This is an object mapping names to folders.  The best ones
-  to include are "lib" and "doc", but if you use "man" to specify a folder
-  full of man pages, they'll get installed just like these ones.
-
-You can use `npm init` in the root of your package in order to get you
-started with a pretty basic package.json file.  See [`npm
-init`](/commands/npm-init) for more info.
-
-### Keeping files *out* of your Package
-
-Use a `.npmignore` file to keep stuff out of your package.  If there's no
-`.npmignore` file, but there *is* a `.gitignore` file, then npm will ignore
-the stuff matched by the `.gitignore` file.  If you *want* to include
-something that is excluded by your `.gitignore` file, you can create an
-empty `.npmignore` file to override it. Like `git`, `npm` looks for
-`.npmignore` and `.gitignore` files in all subdirectories of your package,
-not only the root directory.
-
-`.npmignore` files follow the [same pattern
-rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring)
-as `.gitignore` files:
-
-* Blank lines or lines starting with `#` are ignored.
-* Standard glob patterns work.
-* You can end patterns with a forward slash `/` to specify a directory.
-* You can negate a pattern by starting it with an exclamation point `!`.
-
-By default, some paths and files are ignored, so there's no
-need to add them to `.npmignore` explicitly. Some examples are:
-
-* `.*.swp`
-* `._*`
-* `.DS_Store`
-* `.git`
-* `.gitignore`
-* `.hg`
-* `.npmignore`
-* `.npmrc`
-* `.lock-wscript`
-* `.svn`
-* `.wafpickle-*`
-* `config.gypi`
-* `CVS`
-* `npm-debug.log`
-
-Additionally, everything in `node_modules` is ignored, except for
-bundled dependencies. npm automatically handles this for you, so don't
-bother adding `node_modules` to `.npmignore`.
-
-The following paths and files are never ignored, so adding them to
-`.npmignore` is pointless:
-
-* `package.json`
-* `README` (and its variants)
-* `LICENSE` / `LICENCE`
-
-If, given the structure of your project, you find `.npmignore` to be a
-maintenance headache, you might instead try populating the `files`
-property of `package.json`, which is an array of file or directory names
-that should be included in your package. Sometimes manually picking
-which items to allow is easier to manage than building a block list.
-
-See [`package.json`](/configuring-npm/package-json) for more info on
-what can and can't be ignored.
-
-#### Testing whether your `.npmignore` or `files` config works
-
-If you want to double check that your package will include only the files
-you intend it to when published, you can run the `npm pack` command locally
-which will generate a tarball in the working directory, the same way it
-does for publishing.
-
-### Link Packages
-
-`npm link` is designed to install a development package and see the
-changes in real time without having to keep re-installing it.  (You do
-need to either re-link or `npm rebuild -g` to update compiled packages,
-of course.)
-
-More info at [`npm link`](/commands/npm-link).
-
-### Before Publishing: Make Sure Your Package Installs and Works
-
-**This is important.**
-
-If you can not install it locally, you'll have
-problems trying to publish it.  Or, worse yet, you'll be able to
-publish it, but you'll be publishing a broken or pointless package.
-So don't do that.
-
-In the root of your package, do this:
-
-```bash
-npm install . -g
-```
-
-That'll show you that it's working.  If you'd rather just create a symlink
-package that points to your working directory, then do this:
-
-```bash
-npm link
-```
-
-Use `npm ls -g` to see if it's there.
-
-To test a local install, go into some other folder, and then do:
-
-```bash
-cd ../some-other-folder
-npm install ../my-package
-```
-
-to install it locally into the node_modules folder in that other place.
-
-Then go into the node-repl, and try using require("my-thing") to
-bring in your module's main module.
-
-### Create a User Account
-
-Create a user with the adduser command.  It works like this:
-
-```bash
-npm adduser
-```
-
-and then follow the prompts.
-
-This is documented better in [npm adduser](/commands/npm-adduser).
-
-### Publish your Package
-
-This part's easy.  In the root of your folder, do this:
-
-```bash
-npm publish
-```
-
-You can give publish a url to a tarball, or a filename of a tarball,
-or a path to a folder.
-
-Note that pretty much **everything in that folder will be exposed**
-by default.  So, if you have secret stuff in there, use a
-`.npmignore` file to list out the globs to ignore, or publish
-from a fresh checkout.
-
-### Brag about it
-
-Send emails, write blogs, blab in IRC.
-
-Tell the world how easy it is to install your program!
-
-### See also
-
-* [npm](/commands/npm)
-* [npm init](/commands/npm-init)
-* [package.json](/configuring-npm/package-json)
-* [npm scripts](/using-npm/scripts)
-* [npm publish](/commands/npm-publish)
-* [npm adduser](/commands/npm-adduser)
-* [npm registry](/using-npm/registry)

package/node/node_modules/npm/docs/content/using-npm/logging.md

@@ -1,96 +0,0 @@
----
-title: Logging
-section: 7
-description: Why, What & How We Log
----
-
-### Description
-
-The `npm` CLI has various mechanisms for showing different levels of information back to end-users for certain commands, configurations & environments.
-
-### Setting Log File Location
-
-All logs are written to a debug log, with the path to that file printed if the execution of a command fails.
-
-The default location of the logs directory is a directory named `_logs` inside the npm cache. This can be changed with the `logs-dir` config option.
-
-For example, if you wanted to write all your logs to the current working directory, you could run: `npm install --logs-dir=.`.  This is especially helpful in debugging a specific `npm` issue as you can run
-a command multiple times with different config values and then diff all the log files.
-
-Log files will be removed from the `logs-dir` when the number of log files exceeds `logs-max`, with the oldest logs being deleted first.
-
-To turn off logs completely set `--logs-max=0`.
-
-### Setting Log Levels
-
-#### `loglevel`
-
-`loglevel` is a global argument/config that can be set to determine the type of information to be displayed.
-
-The default value of `loglevel` is `"notice"` but there are several levels/types of logs available, including:
-
-- `"silent"`
-- `"error"`
-- `"warn"`
-- `"notice"`
-- `"http"`
-- `"info"`
-- `"verbose"`
-- `"silly"`
-
-All logs pertaining to a level preceding the current setting will be shown.
-
-##### Aliases
-
-The log levels listed above have various corresponding aliases, including:
-
-- `-d`: `--loglevel info`
-- `--dd`: `--loglevel verbose`
-- `--verbose`: `--loglevel verbose`
-- `--ddd`: `--loglevel silly`
-- `-q`: `--loglevel warn`
-- `--quiet`: `--loglevel warn`
-- `-s`: `--loglevel silent`
-- `--silent`: `--loglevel silent`
-
-#### `foreground-scripts`
-
-The `npm` CLI began hiding the output of lifecycle scripts for `npm install` as of `v7`. Notably, this means you will not see logs/output from packages that may be using "install scripts" to display information back to you or from your own project's scripts defined in `package.json`. If you'd like to change this behavior & log this output you can set `foreground-scripts` to `true`.
-
-### Timing Information
-
-The [`--timing` config](/using-npm/config#timing) can be set which does a few
-things:
-
-1. Always shows the full path to the debug log regardless of command exit status
-1. Write timing information to a process specific timing file in the cache or `logs-dir`
-1. Output timing information to the terminal
-
-This file contains a `timers` object where the keys are an identifier for the
-portion of the process being timed and the value is the number of milliseconds it took to complete.
-
-Sometimes it is helpful to get timing information without outputting anything to the terminal. For
-example, the performance might be affected by writing to the terminal. In this case you can use
-`--timing --silent` which will still write the timing file, but not output anything to the terminal
-while running.
-
-### Registry Response Headers
-
-#### `npm-notice`
-
-The `npm` CLI reads from & logs any `npm-notice` headers that are returned from the configured registry. This mechanism can be used by third-party registries to provide useful information when network-dependent requests occur.
-
-This header is not cached, and will not be logged if the request is served from the cache.
-
-### Logs and Sensitive Information
-
-The `npm` CLI makes a best effort to redact the following from terminal output and log files:
-
-- Passwords inside basic auth URLs
-- npm tokens
-
-However, this behavior should not be relied on to keep all possible sensitive information redacted. If you are concerned about secrets in your log file or terminal output, you can use `--loglevel=silent` and `--logs-max=0` to ensure no logs are written to your terminal or filesystem.
-
-### See also
-
-* [config](/using-npm/config)

package/node/node_modules/npm/docs/content/using-npm/orgs.md

@@ -1,93 +0,0 @@
----
-title: orgs
-section: 7
-description: Working with Teams & Orgs
----
-
-### Description
-
-There are three levels of org users:
-
-1. Super admin, controls billing & adding people to the org.
-2. Team admin, manages team membership & package access.
-3. Developer, works on packages they are given access to.  
-
-The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a `developers` team that all users are automatically added to.
-
-The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals.
-
-The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.
-
-There are two main commands:
-
-1. `npm team` see [npm team](/commands/npm-team) for more details
-2. `npm access` see [npm access](/commands/npm-access) for more details
-
-### Team Admins create teams
-
-* Check who you’ve added to your org:
-
-```bash
-npm team ls <org>:developers
-```
-
-* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the `access` command.
-
-* Create a new team:
-
-```bash
-npm team create <org:team>
-```
-
-* Add members to that team:
-
-```bash
-npm team add <org:team> <user>
-```
-
-### Publish a package and adjust package access
-
-* In package directory, run
-
-```bash
-npm init --scope=<org>
-```
-to scope it for your org & publish as usual
-
-* Grant access:  
-
-```bash
-npm access grant <read-only|read-write> <org:team> [<package>]
-```
-
-* Revoke access:
-
-```bash
-npm access revoke <org:team> [<package>]
-```
-
-### Monitor your package access
-
-* See what org packages a team member can access:
-
-```bash
-npm access ls-packages <org> <user>
-```
-
-* See packages available to a specific team:
-
-```bash
-npm access ls-packages <org:team>
-```
-
-* Check which teams are collaborating on a package:
-
-```bash
-npm access ls-collaborators <pkg>
-```
-
-### See also
-
-* [npm team](/commands/npm-team)
-* [npm access](/commands/npm-access)
-* [npm scope](/using-npm/scope)