@smithery/api 0.11.0 → 0.13.0

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

@@ -1,247 +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](https://ci.testling.com/guide/advanced_configuration) 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/oidc/node_modules/npm/docs/content/using-npm/developers.md

@@ -1,215 +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 cannot 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/oidc/node_modules/npm/docs/content/using-npm/logging.md

@@ -1,99 +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/oidc/node_modules/npm/docs/content/using-npm/orgs.md

@@ -1,98 +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 list packages <org> <user>
-```
-
-* See packages available to a specific team:
-
-```bash
-npm access list packages <org:team>
-```
-
-* Check which teams are collaborating on a package:
-
-```bash
-npm access list collaborators <pkg>
-```
-
-### See also
-
-* [npm team](/commands/npm-team)
-* [npm access](/commands/npm-access)
-* [npm scope](/using-npm/scope)