@smithery/api 0.11.0 → 0.13.0

package/oidc/node_modules/npm/docs/content/commands/npm-diff.md

@@ -1,285 +0,0 @@
----
-title: npm-diff
-section: 1
-description: The registry diff command
----
-
-### Synopsis
-
-```bash
-npm diff [...<paths>]
-```
-
-### Description
-
-Similar to its `git diff` counterpart, this command will print diff patches of files for packages published to the npm registry.
-
-* `npm diff --diff=<spec-a> --diff=<spec-b>`
-
-    Compares two package versions using their registry specifiers, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0`.
-    It's also possible to compare across forks of any package, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0`.
-
-    Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: `npm diff --diff=pkg@latest --diff=./packages/pkg`
-
-    Here's an example comparing two different versions of a package named `abbrev` from the registry:
-
-    ```bash
-    npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
-    ```
-
-    On success, output looks like:
-
-    ```bash
-    diff --git a/package.json b/package.json
-    index v1.1.0..v1.1.1 100644
-    --- a/package.json
-    +++ b/package.json
-    @@ -1,6 +1,6 @@
-     {
-       "name": "abbrev",
-    -  "version": "1.1.0",
-    +  "version": "1.1.1",
-       "description": "Like ruby's abbrev module, but in js",
-       "author": "Isaac Z. Schlueter <i@izs.me>",
-       "main": "abbrev.js",
-    ```
-
-    Given the flexible nature of npm specs, you can also target local directories or git repos just like when using `npm install`:
-
-    ```bash
-    npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
-    ```
-
-    In the example above we can compare the contents from the package installed from the git repo at `github.com/npm/libnpmdiff` with the contents of the `./local-path` that contains a valid package, such as a modified copy of the original.
-
-* `npm diff` (in a package directory, no arguments):
-
-    If the package is published to the registry, `npm diff` will fetch the tarball version tagged as `latest` (this value can be configured using the `tag` option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
-
-    This workflow provides a handy way for package authors to see what package-tracked files have been changed in comparison with the latest published version of that package.
-
-* `npm diff --diff=<pkg-name>` (in a package directory):
-
-    When using a single package name (with no version or tag specifier) as an argument, `npm diff` will work in a similar way to [`npm-outdated`](npm-outdated) and reach for the registry to figure out what current published version of the package named `<pkg-name>` will satisfy its dependent declared semver-range.
-    Once that specific version is known `npm diff` will print diff patches comparing the current version of `<pkg-name>` found in the local file system with that specific version returned by the registry.
-
-    Given a package named `abbrev` that is currently installed:
-
-    ```bash
-    npm diff --diff=abbrev
-    ```
-
-    That will request from the registry its most up to date version and will print a diff output comparing the currently installed version to this newer one if the version numbers are not the same.
-
-* `npm diff --diff=<spec-a>` (in a package directory):
-
-    Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in `<spec-a>`.
-
-    An example: assuming `pkg@1.0.0` is installed in the current `node_modules` folder, running:
-
-    ```bash
-    npm diff --diff=pkg@2.0.0
-    ```
-
-    It will effectively be an alias to
-    `npm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0`.
-
-* `npm diff --diff=<semver-a> [--diff=<semver-b>]` (in a package directory):
-
-    Using `npm diff` along with semver-valid version numbers is a shorthand to compare different versions of the current package.
-
-    It needs to be run from a package directory, such that for a package named `pkg` running `npm diff --diff=1.0.0 --diff=1.0.1` is the same as running `npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1`.
-
-    If only a single argument `<version-a>` is provided, then the current local file system is going to be compared against that version.
-
-    Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
-
-    ```bash
-    npm diff --diff=1.0.0 --diff=1.1.0
-    ```
-
-Note that tag names are not valid `--diff` argument values, if you wish to compare to a published tag, you must use the `pkg@tagname` syntax.
-
-#### Filtering files
-
-It's possible to also specify positional arguments using file names or globs pattern matching in order to limit the result of diff patches to only a subset of files for a given package, e.g:
-
-  ```bash
-  npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
-  ```
-
-In the example above the diff output is only going to print contents of files located within the folder `./lib/` and changed lines of code within the `CHANGELOG.md` file.
-
-### Configuration
-
-#### `diff`
-
-* Default:
-* Type: String (can be set multiple times)
-
-Define arguments to compare in `npm diff`.
-
-
-
-#### `diff-name-only`
-
-* Default: false
-* Type: Boolean
-
-Prints only filenames when using `npm diff`.
-
-
-
-#### `diff-unified`
-
-* Default: 3
-* Type: Number
-
-The number of lines of context to print in `npm diff`.
-
-
-
-#### `diff-ignore-all-space`
-
-* Default: false
-* Type: Boolean
-
-Ignore whitespace when comparing lines in `npm diff`.
-
-
-
-#### `diff-no-prefix`
-
-* Default: false
-* Type: Boolean
-
-Do not show any source or destination prefix in `npm diff` output.
-
-Note: this causes `npm diff` to ignore the `--diff-src-prefix` and
-`--diff-dst-prefix` configs.
-
-
-
-#### `diff-src-prefix`
-
-* Default: "a/"
-* Type: String
-
-Source prefix to be used in `npm diff` output.
-
-
-
-#### `diff-dst-prefix`
-
-* Default: "b/"
-* Type: String
-
-Destination prefix to be used in `npm diff` output.
-
-
-
-#### `diff-text`
-
-* Default: false
-* Type: Boolean
-
-Treat all files as text in `npm diff`.
-
-
-
-#### `global`
-
-* Default: false
-* Type: Boolean
-
-Operates in "global" mode, so that packages are installed into the
-`prefix` folder instead of the current working directory. See
-[folders](/configuring-npm/folders) for more on the differences in
-behavior.
-
-* packages are installed into the `{prefix}/lib/node_modules` folder,
-  instead of the current working directory.
-* bin files are linked to `{prefix}/bin`
-* man pages are linked to `{prefix}/share/man`
-
-
-
-#### `tag`
-
-* Default: "latest"
-* Type: String
-
-If you ask npm to install a package and don't tell it a specific
-version, then it will install the specified tag.
-
-It is the tag added to the package@version specified in the `npm
-dist-tag add` command, if no explicit tag is given.
-
-When used by the `npm diff` command, this is the tag used to fetch
-the tarball that will be compared with the local files by default.
-
-If used in the `npm publish` command, this is the tag that will be
-added to the package submitted to the registry.
-
-
-
-#### `workspace`
-
-* Default:
-* Type: String (can be set multiple times)
-
-Enable running a command in the context of the configured workspaces
-of the current project while filtering by running only the workspaces
-defined by this configuration option.
-
-Valid values for the `workspace` config are either:
-
-* Workspace names
-* Path to a workspace directory
-* Path to a parent workspace directory (will result in selecting all
-  workspaces within that folder)
-
-When set for the `npm init` command, this may be set to the folder of
-a workspace which does not yet exist, to create the folder and set it
-up as a brand new workspace within the project.
-
-This value is not exported to the environment for child processes.
-
-#### `workspaces`
-
-* Default: null
-* Type: null or Boolean
-
-Set to true to run the command in the context of **all** configured
-workspaces.
-
-Explicitly setting this to false will cause commands like `install`
-to ignore workspaces altogether. When not set explicitly:
-
-- Commands that operate on the `node_modules` tree (install, update,
-etc.) will link workspaces into the `node_modules` folder. - Commands
-that do other things (test, exec, publish, etc.) will operate on the
-root project, _unless_ one or more workspaces are specified in the
-`workspace` config.
-
-This value is not exported to the environment for child processes.
-
-#### `include-workspace-root`
-
-* Default: false
-* Type: Boolean
-
-Include the workspace root when workspaces are enabled for a command.
-
-When false, specifying individual workspaces via the `workspace`
-config, or all workspaces via the `workspaces` flag, will cause npm
-to operate only on the specified workspaces, and not on the root
-project.
-
-This value is not exported to the environment for child processes.
-## See Also
-
-* [npm outdated](/commands/npm-outdated)
-* [npm install](/commands/npm-install)
-* [npm config](/commands/npm-config)
-* [npm registry](/using-npm/registry)

package/oidc/node_modules/npm/docs/content/commands/npm-dist-tag.md

@@ -1,140 +0,0 @@
----
-title: npm-dist-tag
-section: 1
-description: Modify package distribution tags
----
-
-### Synopsis
-
-```bash
-npm dist-tag add <package-spec (with version)> [<tag>]
-npm dist-tag rm <package-spec> <tag>
-npm dist-tag ls [<package-spec>]
-
-alias: dist-tags
-```
-
-### Description
-
-Add, remove, and enumerate distribution tags on a package:
-
-* add: Tags the specified version of the package with the specified tag, or the [`--tag` config](/using-npm/config#tag) if not specified.
-  If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`.
-
-* rm: Clear a tag that is no longer in use from the package.
-  If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`
-
-* ls: Show all of the dist-tags for a package, defaulting to the package in the current prefix.
-  This is the default action if none is specified.
-
-A tag can be used when installing packages as a reference to a version instead of using a specific version number:
-
-```bash
-npm install <name>@<tag>
-```
-
-When installing dependencies, a preferred tagged version may be specified:
-
-```bash
-npm install --tag <tag>
-```
-
-(This also applies to any other commands that resolve and install dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.)
-
-Publishing a package sets the `latest` tag to the published version unless the `--tag` option is used.
-For example, `npm publish --tag=beta`.
-
-By default, `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag.
-
-### Purpose
-
-Tags can be used to provide an alias instead of version numbers.
-
-For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., `stable`, `beta`, `dev`,
-`canary`.
-
-By default, the `latest` tag is used by npm to identify the current version of a package, and `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag.
-Typically, projects only use the `latest` tag for stable release versions, and use other tags for unstable versions such as prereleases.
-
-The `next` tag is used by some projects to identify the upcoming version.
-
-Other than `latest`, no tag has any special significance to npm itself.
-
-### Caveats
-
-This command used to be known as `npm tag`, which only created new tags, and so had a different syntax.
-
-Tags must share a namespace with version numbers, because they are specified in the same slot: `npm install <pkg>@<version>` vs `npm install <pkg>@<tag>`.
-
-Tags that can be interpreted as valid semver ranges will be rejected.
-For example, `v1.4` cannot be used as a tag, because it is interpreted by semver as `>=1.4.0 <1.5.0`.
-See <https://github.com/npm/npm/issues/6082>.
-
-The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter `v`.
-
-### Configuration
-
-#### `workspace`
-
-* Default:
-* Type: String (can be set multiple times)
-
-Enable running a command in the context of the configured workspaces
-of the current project while filtering by running only the workspaces
-defined by this configuration option.
-
-Valid values for the `workspace` config are either:
-
-* Workspace names
-* Path to a workspace directory
-* Path to a parent workspace directory (will result in selecting all
-  workspaces within that folder)
-
-When set for the `npm init` command, this may be set to the folder of
-a workspace which does not yet exist, to create the folder and set it
-up as a brand new workspace within the project.
-
-This value is not exported to the environment for child processes.
-
-#### `workspaces`
-
-* Default: null
-* Type: null or Boolean
-
-Set to true to run the command in the context of **all** configured
-workspaces.
-
-Explicitly setting this to false will cause commands like `install`
-to ignore workspaces altogether. When not set explicitly:
-
-- Commands that operate on the `node_modules` tree (install, update,
-etc.) will link workspaces into the `node_modules` folder. - Commands
-that do other things (test, exec, publish, etc.) will operate on the
-root project, _unless_ one or more workspaces are specified in the
-`workspace` config.
-
-This value is not exported to the environment for child processes.
-
-#### `include-workspace-root`
-
-* Default: false
-* Type: Boolean
-
-Include the workspace root when workspaces are enabled for a command.
-
-When false, specifying individual workspaces via the `workspace`
-config, or all workspaces via the `workspaces` flag, will cause npm
-to operate only on the specified workspaces, and not on the root
-project.
-
-This value is not exported to the environment for child processes.
-
-### See Also
-
-* [package spec](/using-npm/package-spec)
-* [npm publish](/commands/npm-publish)
-* [npm install](/commands/npm-install)
-* [npm dedupe](/commands/npm-dedupe)
-* [npm registry](/using-npm/registry)
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)

package/oidc/node_modules/npm/docs/content/commands/npm-docs.md

@@ -1,108 +0,0 @@
----
-title: npm-docs
-section: 1
-description: Open documentation for a package in a web browser
----
-
-### Synopsis
-
-```bash
-npm docs [<pkgname> [<pkgname> ...]]
-
-alias: home
-```
-
-### Description
-
-This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the [`--browser` config](/using-npm/config#browser) param.
-You can pass multiple package names at once.
-If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property.
-
-### Configuration
-
-#### `browser`
-
-* Default: macOS: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
-* Type: null, Boolean, or String
-
-The browser that is called by npm commands to open websites.
-
-Set to `false` to suppress browser behavior and instead print urls to
-terminal.
-
-Set to `true` to use default system URL opener.
-
-
-
-#### `registry`
-
-* Default: "https://registry.npmjs.org/"
-* Type: URL
-
-The base URL of the npm registry.
-
-
-
-#### `workspace`
-
-* Default:
-* Type: String (can be set multiple times)
-
-Enable running a command in the context of the configured workspaces
-of the current project while filtering by running only the workspaces
-defined by this configuration option.
-
-Valid values for the `workspace` config are either:
-
-* Workspace names
-* Path to a workspace directory
-* Path to a parent workspace directory (will result in selecting all
-  workspaces within that folder)
-
-When set for the `npm init` command, this may be set to the folder of
-a workspace which does not yet exist, to create the folder and set it
-up as a brand new workspace within the project.
-
-This value is not exported to the environment for child processes.
-
-#### `workspaces`
-
-* Default: null
-* Type: null or Boolean
-
-Set to true to run the command in the context of **all** configured
-workspaces.
-
-Explicitly setting this to false will cause commands like `install`
-to ignore workspaces altogether. When not set explicitly:
-
-- Commands that operate on the `node_modules` tree (install, update,
-etc.) will link workspaces into the `node_modules` folder. - Commands
-that do other things (test, exec, publish, etc.) will operate on the
-root project, _unless_ one or more workspaces are specified in the
-`workspace` config.
-
-This value is not exported to the environment for child processes.
-
-#### `include-workspace-root`
-
-* Default: false
-* Type: Boolean
-
-Include the workspace root when workspaces are enabled for a command.
-
-When false, specifying individual workspaces via the `workspace`
-config, or all workspaces via the `workspaces` flag, will cause npm
-to operate only on the specified workspaces, and not on the root
-project.
-
-This value is not exported to the environment for child processes.
-
-### See Also
-
-* [npm view](/commands/npm-view)
-* [npm publish](/commands/npm-publish)
-* [npm registry](/using-npm/registry)
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)
-* [package.json](/configuring-npm/package-json)

package/oidc/node_modules/npm/docs/content/commands/npm-doctor.md

@@ -1,98 +0,0 @@
----
-title: npm-doctor
-section: 1
-description: Check the health of your npm environment
----
-
-### Synopsis
-
-```bash
-npm doctor [connection] [registry] [versions] [environment] [permissions] [cache]
-```
-
-Note: This command is unaware of workspaces.
-
-### Description
-
-`npm doctor` runs a set of checks to ensure that your npm installation has what it needs to manage your JavaScript packages.
-npm is mostly a standalone tool, but it does have some basic requirements that must be met:
-
-+ Node.js and git must be executable by npm.
-+ The primary npm registry, `registry.npmjs.com`, or another service that uses the registry API, is available.
-+ The directories that npm uses, `node_modules` (both locally and globally), exist and can be written by the current user.
-+ The npm cache exists, and the package tarballs within it aren't corrupt.
-
-Without all of these working properly, npm may not work properly.
-Many issues are often attributable to things that are outside npm's code base, so `npm doctor` confirms that the npm installation is in a good state.
-
-Also, in addition to this, there are also very many issue reports due to using old versions of npm.
-Since npm is constantly improving, running `npm@latest` is better than an old version.
-
-`npm doctor` verifies the following items in your environment, and if there are any recommended changes, it will display them.
-By default npm runs all of these checks.
-You can limit what checks are ran by specifying them as extra arguments.
-
-#### `Connecting to the registry`
-
-By default, npm installs from the primary npm registry,
-`registry.npmjs.org`.
-`npm doctor` hits a special connection testing endpoint within the registry.
-This can also be checked with `npm ping`.
-If this check fails, you may be using a proxy that needs to be configured, or may need to talk to your IT staff to get access over HTTPS to `registry.npmjs.org`.
-
-This check is done against whichever registry you've configured (you can see what that is by running `npm config get registry`), and if you're using a private registry that doesn't support the `/whoami` endpoint supported by the primary registry, this check may fail.
-
-#### `Checking npm version`
-
-While Node.js may come bundled with a particular version of npm, it's the policy of the CLI team that we recommend all users run `npm@latest` if they can.
-As the CLI is maintained by a small team of contributors, there are only resources for a single line of development, so npm's own long-term support releases typically only receive critical security and regression fixes.
-The team believes that the latest tested version of npm is almost always likely to be the most functional and defect-free version of npm.
-
-#### `Checking node version`
-
-For most users, in most circumstances, the best version of Node will be the latest long-term support (LTS) release.
-Those of you who want access to new ECMAscript features or bleeding-edge changes to Node's standard library may be running a newer version, and some may be required to run an older version of Node because of enterprise change control policies.
-That's OK!
-But in general, the npm team recommends that most users run Node.js LTS.
-
-#### `Checking configured npm registry`
-
-You may be installing from private package registries for your project or company.
-That's great! Others may be following tutorials or StackOverflow questions in an effort to troubleshoot problems you may be having.
-Sometimes, this may entail changing the registry you're pointing at.
-This part of `npm doctor` just lets you, and maybe whoever's helping you with support, know that you're not using the default registry.
-
-#### `Checking for git executable in PATH`
-
-While it's documented in the README, it may not be obvious that npm needs Git installed to do many of the things that it does.
-Also, in some cases – especially on Windows – you may have Git set up in such a way that it's not accessible via your `PATH` so that npm can find it.
-This check ensures that Git is available.
-
-#### Permissions checks
-
-* Your cache must be readable and writable by the user running npm.
-* Global package binaries must be writable by the user running npm.
-* Your local `node_modules` path, if you're running `npm doctor` with a project directory, must be readable and writable by the user running npm.
-
-#### Validate the checksums of cached packages
-
-When an npm package is published, the publishing process generates a checksum that npm uses at install time to verify that the package didn't get corrupted in transit.
-`npm doctor` uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with `npm config get cache`).
-In the event that there are corrupt packages in your cache, you should probably run `npm cache clean -f` and reset the cache.
-
-### Configuration
-
-#### `registry`
-
-* Default: "https://registry.npmjs.org/"
-* Type: URL
-
-The base URL of the npm registry.
-
-
-
-### See Also
-
-* [npm bugs](/commands/npm-bugs)
-* [npm help](/commands/npm-help)
-* [npm ping](/commands/npm-ping)

package/oidc/node_modules/npm/docs/content/commands/npm-edit.md

@@ -1,41 +0,0 @@
----
-title: npm-edit
-section: 1
-description: Edit an installed package
----
-
-### Synopsis
-
-```bash
-npm edit <pkg>[/<subpkg>...]
-```
-
-Note: This command is unaware of workspaces.
-
-### Description
-
-Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm `editor` config -- see [`npm-config`](npm-config).)
-
-After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
-
-For instance, you can do `npm install connect` to install connect into your package, and then `npm edit connect` to make a few changes to your locally installed copy.
-
-### Configuration
-
-#### `editor`
-
-* Default: The EDITOR or VISUAL environment variables, or
-  '%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
-* Type: String
-
-The command to run for `npm edit` and `npm config edit`.
-
-
-
-### See Also
-
-* [npm folders](/configuring-npm/folders)
-* [npm explore](/commands/npm-explore)
-* [npm install](/commands/npm-install)
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)