@surgeapi/node 0.30.0 → 0.31.0

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

@@ -1,225 +0,0 @@
----
-title: npm-version
-section: 1
-description: Bump a package version
----
-
-### Synopsis
-
-```bash
-npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git]
-
-alias: verison
-```
-
-### Configuration
-
-#### `allow-same-version`
-
-* Default: false
-* Type: Boolean
-
-Prevents throwing an error when `npm version` is used to set the new
-version to the same value as the current version.
-
-
-
-#### `commit-hooks`
-
-* Default: true
-* Type: Boolean
-
-Run git commit hooks when using the `npm version` command.
-
-
-
-#### `git-tag-version`
-
-* Default: true
-* Type: Boolean
-
-Tag the commit when using the `npm version` command. Setting this to
-false results in no commit being made at all.
-
-
-
-#### `json`
-
-* Default: false
-* Type: Boolean
-
-Whether or not to output JSON data, rather than the normal output.
-
-* In `npm pkg set` it enables parsing set values with JSON.parse()
-  before saving them to your `package.json`.
-
-Not supported by all npm commands.
-
-
-
-#### `preid`
-
-* Default: ""
-* Type: String
-
-The "prerelease identifier" to use as a prefix for the "prerelease"
-part of a semver. Like the `rc` in `1.2.0-rc.8`.
-
-
-
-#### `sign-git-tag`
-
-* Default: false
-* Type: Boolean
-
-If set to true, then the `npm version` command will tag the version
-using `-s` to add a signature.
-
-Note that git requires you to have set up GPG keys in your git
-configs for this to work properly.
-
-
-
-#### `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.
-
-#### `workspaces-update`
-
-* Default: true
-* Type: Boolean
-
-If set to true, the npm cli will run an update after operations that
-may possibly change the workspaces installed to the `node_modules`
-folder.
-
-
-
-#### `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.
-
-### Description
-
-Run this in a package directory to bump the version and write the new data back to `package.json`, `package-lock.json`, and, if present,
-`npm-shrinkwrap.json`.
-
-The `newversion` argument should be a valid semver string, a valid second argument to [semver.inc](https://github.com/npm/node-semver#functions) (one of `patch`, `minor`, `major`, `prepatch`, `preminor`, `premajor`, `prerelease`), or `from-git`.
-In the second case, the existing version will be incremented by 1 in the specified field.
-`from-git` will try to read the latest git tag, and use that as the new npm version.
-
-If run in a git repo, it will also create a version commit and tag.
-This behavior is controlled by `git-tag-version` (see below), and can be disabled on the command line by running `npm --no-git-tag-version version`.
-It will fail if the working directory is not clean, unless the `-f` or `--force` flag is set.
-
-If supplied with `-m` or [`--message` config](/using-npm/config#message) option, npm will use it as a commit message when creating a version commit.
-If the `message` config contains `%s` then that will be replaced with the resulting version number.
-For example:
-
-```bash
-npm version patch -m "Upgrade to %s for reasons"
-```
-
-If the [`sign-git-tag` config](/using-npm/config#sign-git-tag) is set, then the tag will be signed using the `-s` flag to git.
-Note that you must have a default GPG key set up in your git config for this to work properly.
-For example:
-
-```bash
-$ npm config set sign-git-tag true
-$ npm version patch
-
-You need a passphrase to unlock the secret key for user: "isaacs (http://blog.izs.me/) <i@izs.me>"
-2048-bit RSA key, ID 6C481CF6, created 2010-08-31
-
-Enter passphrase:
-```
-
-If `preversion`, `version`, or `postversion` are in the `scripts` property of the package.json, they will be executed as part of running `npm version`.
-
-The exact order of execution is as follows:
-
-1. Check to make sure the git working directory is clean before we get started.
-   Your scripts may add files to the commit in future steps.
-   This step is skipped if the `--force` flag is set.
-2. Run the `preversion` script.
-   These scripts have access to the old `version` in package.json.
-   A typical use would be running your full test suite before deploying.
-   Any files you want added to the commit should be explicitly added using `git add`.
-3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc).
-4. Run the `version` script.
-   These scripts have access to the new `version` in package.json (so they can incorporate it into file headers in generated files for example).
-   Again, scripts should explicitly add generated files to the commit using `git add`.
-5. Commit and tag.
-6. Run the `postversion` script.
-   Use it to clean up the file system or automatically push the commit and/or tag.
-
-Take the following example:
-
-```json
-{
-  "scripts": {
-    "preversion": "npm test",
-    "version": "npm run build && git add -A dist",
-    "postversion": "git push && git push --tags && rm -rf build/temp"
-  }
-}
-```
-
-This runs all your tests and proceeds only if they pass.
-Then runs your `build` script, and adds everything in the `dist` directory to the commit.
-After the commit, it pushes the new commit and tag up to the server, and deletes the `build/temp` directory.
-
-### See Also
-
-* [npm init](/commands/npm-init)
-* [npm run](/commands/npm-run)
-* [npm scripts](/using-npm/scripts)
-* [package.json](/configuring-npm/package-json)
-* [config](/using-npm/config)

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

@@ -1,194 +0,0 @@
----
-title: npm-view
-section: 1
-description: View registry info
----
-
-### Synopsis
-
-```bash
-npm view [<package-spec>] [<field>[.subfield]...]
-
-aliases: info, show, v
-```
-
-### Description
-
-This command shows data about a package and prints it to stdout.
-
-As an example, to view information about the `connect` package from the registry, you would run:
-
-```bash
-npm view connect
-```
-
-The default version is `"latest"` if unspecified.
-
-Field names can be specified after the package descriptor.
-For example, to show the dependencies of the `ronn` package at version
-`0.3.5`, you could do the following:
-
-```bash
-npm view ronn@0.3.5 dependencies
-```
-
-By default, `npm view` shows data about the current project context (by looking for a `package.json`).
-To show field data for the current project use a file path (i.e.
-`.`):
-
-```bash
-npm view . dependencies
-```
-
-You can view child fields by separating them with a period.
-To view the git repository URL for the latest version of `npm`, you would run the following command:
-
-```bash
-npm view npm repository.url
-```
-
-This makes it easy to view information about a dependency with a bit of shell scripting.
-For example, to view all the data about the version of `opts` that `ronn` depends on, you could write the following:
-
-```bash
-npm view opts@$(npm view ronn dependencies.opts)
-```
-
-For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list.
-For example, to get all the contributor email addresses for the `express` package, you would run:
-
-```bash
-npm view express contributors.email
-```
-
-You may also use numeric indices in square braces to specifically select an item in an array field.
-To just get the email address of the first contributor in the list, you can run:
-
-```bash
-npm view express contributors[0].email
-```
-
-If the field value you are querying for is a property of an object, you should run:
-
-```bash
-npm view express time'[4.8.0]'
-```
-
-Multiple fields may be specified, and will be printed one after another.
-For example, to get all the contributor names and email addresses, you can do this:
-
-```bash
-npm view express contributors.name contributors.email
-```
-
-"Person" fields are shown as a string if they would be shown as an object.
-So, for example, this will show the list of `npm` contributors in the shortened string format.
- (See [`package.json`](/configuring-npm/package-json) for more on this.)
-
-```bash
-npm view npm contributors
-```
-
-If a version range is provided, then data will be printed for every matching version of the package.
-This will show which version of `jsdom` was required by each matching version of `yui3`:
-
-```bash
-npm view yui3@'>0.5.4' dependencies.jsdom
-```
-
-To show the `connect` package version history, you can do this:
-
-```bash
-npm view connect versions
-```
-
-### Configuration
-
-#### `json`
-
-* Default: false
-* Type: Boolean
-
-Whether or not to output JSON data, rather than the normal output.
-
-* In `npm pkg set` it enables parsing set values with JSON.parse()
-  before saving them to your `package.json`.
-
-Not supported by all npm commands.
-
-
-
-#### `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.
-
-### Output
-
-If only a single string field for a single version is output, then it will not be colorized or quoted, to enable piping the output to another command.
-If the field is an object, it will be output as a JavaScript object literal.
-
-If the `--json` flag is given, the outputted fields will be JSON.
-
-If the version range matches multiple versions then each printed value will be prefixed with the version it applies to.
-
-If multiple fields are requested, then each of them is prefixed with the field name.
-
-### See Also
-
-* [package spec](/using-npm/package-spec)
-* [npm search](/commands/npm-search)
-* [npm registry](/using-npm/registry)
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)
-* [npm docs](/commands/npm-docs)

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

@@ -1,38 +0,0 @@
----
-title: npm-whoami
-section: 1
-description: Display npm username
----
-
-### Synopsis
-
-```bash
-npm whoami
-```
-
-Note: This command is unaware of workspaces.
-
-### Description
-
-Display the npm username of the currently logged-in user.
-
-If logged into a registry that provides token-based authentication, then connect to the `/-/whoami` registry endpoint to find the username associated with the token, and print to standard output.
-
-If logged into a registry that uses Basic Auth, then simply print the `username` portion of the authentication string.
-
-### Configuration
-
-#### `registry`
-
-* Default: "https://registry.npmjs.org/"
-* Type: URL
-
-The base URL of the npm registry.
-
-
-
-### See Also
-
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)
-* [npm adduser](/commands/npm-adduser)

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

@@ -1,148 +0,0 @@
----
-title: npm
-section: 1
-description: javascript package manager
----
-
-### Synopsis
-
-```bash
-npm
-```
-
-Note: This command is unaware of workspaces.
-
-### Version
-
-11.6.2
-
-### Description
-
-npm is the package manager for the Node JavaScript platform.
-It puts modules in place so that node can find them, and manages dependency conflicts intelligently.
-
-It is extremely configurable to support a variety of use cases.
-Most commonly, you use it to publish, discover, install, and develop node programs.
-
-Run `npm help` to get a list of available commands.
-
-### Important
-
-npm comes preconfigured to use npm's public registry at https://registry.npmjs.org by default.
-Use of the npm public registry is subject to terms of use available at https://docs.npmjs.com/policies/terms.
-
-You can configure npm to use any compatible registry you like, and even run your own registry.
-Use of someone else's registry is governed by their terms of use.
-
-### Introduction
-
-You probably got npm because you want to install stuff.
-
-The very first thing you will most likely want to run in any node program is `npm install` to install its dependencies.
-
-You can also run `npm install blerg` to install the latest version of "blerg".  Check out [`npm install`](/commands/npm-install) for more info.
-It can do a lot of stuff.
-
-Use the `npm search` command to show everything that's available in the public registry.
-Use `npm ls` to show everything you've installed.
-
-### Dependencies
-
-If a package lists a dependency using a git URL, npm will install that dependency using the [`git`](https://github.com/git-guides/install-git) command and will generate an error if it is not installed.
-
-If one of the packages npm tries to install is a native node module and requires compiling of C++ Code, npm will use [node-gyp](https://github.com/nodejs/node-gyp) for that task.
-For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp) needs Python, make and a buildchain like GCC. On Windows, Python and Microsoft Visual Studio C++ are needed.
-For more information visit [the node-gyp repository](https://github.com/nodejs/node-gyp) and the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki).
-
-### Directories
-
-See [`folders`](/configuring-npm/folders) to learn about where npm puts stuff.
-
-In particular, npm has two modes of operation:
-
-* local mode:
-  npm installs packages into the current project directory, which defaults to the current working directory.
-  Packages install to `./node_modules`, and bins to `./node_modules/.bin`.
-* global mode:
-  npm installs packages into the install prefix at `$npm_config_prefix/lib/node_modules` and bins to `$npm_config_prefix/bin`.
-
-Local mode is the default.
-Use `-g` or `--global` on any command to run in global mode instead.
-
-### Developer Usage
-
-If you're using npm to develop and publish your code, check out the following help topics:
-
-* json:
-  Make a package.json file.
-  See [`package.json`](/configuring-npm/package-json).
-* link:
-  Links your current working code into Node's path, so that you don't have to reinstall every time you make a change.
-  Use [`npm link`](/commands/npm-link) to do this.
-* install:
-  It's a good idea to install things if you don't need the symbolic link.
-  Especially, installing other peoples code from the registry is done via [`npm install`](/commands/npm-install)
-* adduser:
-  Create an account or log in.
-  When you do this, npm will store credentials in the user config file.
-* publish:
-  Use the [`npm publish`](/commands/npm-publish) command to upload your code to the registry.
-
-#### Configuration
-
-npm is extremely configurable.
-It reads its configuration options from 5 places.
-
-* Command line switches:
-  Set a config with `--key val`.
-  All keys take a value, even if they are booleans (the config parser doesn't know what the options are at the time of parsing).
-  If you do not provide a value (`--key`) then the option is set to boolean `true`.
-* Environment Variables:
-  Set any config by prefixing the name in an environment variable with `npm_config_`.
-  For example, `export npm_config_key=val`.
-* User Configs:
-  The file at `$HOME/.npmrc` is an ini-formatted list of configs.
-  If present, it is parsed.
-  If the `userconfig` option is set in the cli or env, that file will be used instead.
-* Global Configs:
-  The file found at `./etc/npmrc` (relative to the global prefix will be parsed if it is found.
-  See [`npm prefix`](/commands/npm-prefix) for more info on the global prefix.
-  If the `globalconfig` option is set in the cli, env, or user config, then that file is parsed instead.
-* Defaults:
-  npm's default configuration options are defined in `lib/utils/config/definitions.js`.
-  These must not be changed.
-
-See [`config`](/using-npm/config) for much, much, more information.
-
-### Contributions
-
-Patches welcome!
-
-If you would like to help, but don't know what to work on, read the [contributing guidelines](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) and check the issues list.
-
-### Bugs
-
-When you find issues, please report them:
-<https://github.com/npm/cli/issues>
-
-Please be sure to follow the template and bug reporting guidelines.
-
-### Feature Requests
-
-Discuss new feature ideas on our discussion forum:
-
-* <https://github.com/orgs/community/discussions/categories/npm>
-
-Or suggest formal RFC proposals:
-
-* <https://github.com/npm/rfcs>
-
-### See Also
-
-* [npm help](/commands/npm-help)
-* [package.json](/configuring-npm/package-json)
-* [npmrc](/configuring-npm/npmrc)
-* [npm config](/commands/npm-config)
-* [npm install](/commands/npm-install)
-* [npm prefix](/commands/npm-prefix)
-* [npm publish](/commands/npm-publish)