@nirvana-labs/nirvana 1.31.1 → 1.32.0

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

@@ -0,0 +1,108 @@
+---
+title: npm-bugs
+section: 1
+description: Report bugs for a package in a web browser
+---
+
+### Synopsis
+
+```bash
+npm bugs [<pkgname> [<pkgname> ...]]
+
+alias: issues
+```
+
+### Description
+
+This command tries to guess at the likely location of a package's bug tracker URL or the `mailto` URL of the support email, and then tries to open it using the [`--browser` config](/using-npm/config#browser) param.
+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 docs](/commands/npm-docs)
+* [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-cache.md

@@ -0,0 +1,100 @@
+---
+title: npm-cache
+section: 1
+description: Manipulates packages cache
+---
+
+### Synopsis
+
+```bash
+npm cache add <package-spec>
+npm cache clean [<key>]
+npm cache ls [<name>@<version>]
+npm cache verify
+npm cache npx ls
+npm cache npx rm [<key>...]
+npm cache npx info <key>...
+```
+
+Note: This command is unaware of workspaces.
+
+### Description
+
+Used to add, list, or clean the `npm cache` folder.
+Also used to view info about entries in the `npm exec` (aka `npx`) cache folder.
+
+#### `npm cache`
+
+* add:
+  Add the specified packages to the local cache.
+  This command is primarily intended to be used internally by npm, but it can provide a way to add data to the local installation cache explicitly.
+
+* clean:
+  Delete a single entry or all entries out of the cache folder.
+  Note that this is typically unnecessary, as npm's cache is self-healing and resistant to data corruption issues.
+
+* ls:
+  List given entries or all entries in the local cache.
+
+* verify:
+  Verify the contents of the cache folder, garbage collecting any unneeded data, and verifying the integrity of the cache index and all cached data.
+
+#### `npm cache npx`
+
+* ls:
+  List all entries in the npx cache.
+
+* rm:
+  Remove given entries or all entries from the npx cache.
+
+* info:
+  Get detailed information about given entries in the npx cache.
+
+### Details
+
+npm stores cache data in an opaque directory within the configured `cache`, named `_cacache`.
+This directory is a [`cacache`](http://npm.im/cacache)-based content-addressable cache that stores all http request data as well as other package-related data.
+This directory is primarily accessed through `pacote`, the library responsible for all package fetching as of npm@5.
+
+All data that passes through the cache is fully verified for integrity on both insertion and extraction.
+Cache corruption will either trigger an error, or signal to `pacote` that the data must be refetched, which it will do automatically.
+For this reason, it should never be necessary to clear the cache for any reason other than reclaiming disk space, thus why `clean` now requires `--force` to run.
+
+There is currently no method exposed through npm to inspect or directly manage the contents of this cache.
+In order to access it, `cacache` must be used directly.
+
+npm will not remove data by itself: the cache will grow as new packages are installed.
+
+### A note about the cache's design
+
+The npm cache is strictly a cache: it should not be relied upon as a persistent and reliable data store for package data.
+npm makes no guarantee that a previously-cached piece of data will be available later, and will automatically delete corrupted contents.
+The primary guarantee that the cache makes is that, if it does return data, that data will be exactly the data that was inserted.
+
+To run an offline verification of existing cache contents, use `npm cache verify`.
+
+### Configuration
+
+#### `cache`
+
+* Default: Windows: `%LocalAppData%\npm-cache`, Posix: `~/.npm`
+* Type: Path
+
+The location of npm's cache directory.
+
+
+
+### See Also
+
+* [package spec](/using-npm/package-spec)
+* [npm folders](/configuring-npm/folders)
+* [npm config](/commands/npm-config)
+* [npmrc](/configuring-npm/npmrc)
+* [npm install](/commands/npm-install)
+* [npm publish](/commands/npm-publish)
+* [npm pack](/commands/npm-pack)
+* [npm exec](/commands/npm-exec)
+* https://npm.im/cacache
+* https://npm.im/pacote
+* https://npm.im/@npmcli/arborist
+* https://npm.im/make-fetch-happen

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

@@ -0,0 +1,321 @@
+---
+title: npm-ci
+section: 1
+description: Clean install a project
+---
+
+### Synopsis
+
+```bash
+npm ci
+
+aliases: clean-install, ic, install-clean, isntall-clean
+```
+
+### Description
+
+This command is similar to [`npm install`](/commands/npm-install), except it's meant to be used in automated environments such as test platforms, continuous integration, and deployment -- or any situation where you want to make sure you're doing a clean install of your dependencies.
+
+The main differences between using `npm install` and `npm ci` are:
+
+* The project **must** have an existing `package-lock.json` or
+  `npm-shrinkwrap.json`.
+* If dependencies in the package lock do not match those in `package.json`,
+  `npm ci` will exit with an error, instead of updating the package lock.
+* `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
+* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
+* It will never write to `package.json` or any of the package-locks:
+  installs are essentially frozen.
+
+NOTE: If you create your `package-lock.json` file by running `npm install` with flags that can affect the shape of your dependency tree, such as
+`--legacy-peer-deps` or `--install-links`, you _must_ provide the same flags to `npm ci` or you are likely to encounter errors.
+An easy way to do this is to run, for example,
+`npm config set legacy-peer-deps=true --location=project` and commit the
+`.npmrc` file to your repo.
+
+### Example
+
+Make sure you have a package-lock and an up-to-date install:
+
+```bash
+$ cd ./my/npm/project
+$ npm install
+added 154 packages in 10s
+$ ls | grep package-lock
+```
+
+Run `npm ci` in that project
+
+```bash
+$ npm ci
+added 154 packages in 5s
+```
+
+Configure Travis CI to build using `npm ci` instead of `npm install`:
+
+```bash
+# .travis.yml
+install:
+- npm ci
+# keep the npm cache around to speed up installs
+cache:
+  directories:
+  - "$HOME/.npm"
+```
+
+### Configuration
+
+#### `install-strategy`
+
+* Default: "hoisted"
+* Type: "hoisted", "nested", "shallow", or "linked"
+
+Sets the strategy for installing packages in node_modules. hoisted
+(default): Install non-duplicated in top-level, and duplicated as
+necessary within directory structure. nested: (formerly
+--legacy-bundling) install in place, no hoisting. shallow (formerly
+--global-style) only install direct deps at top-level. linked:
+(experimental) install in node_modules/.store, link in place,
+unhoisted.
+
+
+
+#### `legacy-bundling`
+
+* Default: false
+* Type: Boolean
+* DEPRECATED: This option has been deprecated in favor of
+  `--install-strategy=nested`
+
+Instead of hoisting package installs in `node_modules`, install
+packages in the same manner that they are depended on. This may cause
+very deep directory structures and duplicate package installs as
+there is no de-duplicating. Sets `--install-strategy=nested`.
+
+
+
+#### `global-style`
+
+* Default: false
+* Type: Boolean
+* DEPRECATED: This option has been deprecated in favor of
+  `--install-strategy=shallow`
+
+Only install direct dependencies in the top level `node_modules`, but
+hoist on deeper dependencies. Sets `--install-strategy=shallow`.
+
+
+
+#### `omit`
+
+* Default: 'dev' if the `NODE_ENV` environment variable is set to
+  'production'; otherwise, empty.
+* Type: "dev", "optional", or "peer" (can be set multiple times)
+
+Dependency types to omit from the installation tree on disk.
+
+Note that these dependencies _are_ still resolved and added to the
+`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
+physically installed on disk.
+
+If a package type appears in both the `--include` and `--omit` lists,
+then it will be included.
+
+If the resulting omit list includes `'dev'`, then the `NODE_ENV`
+environment variable will be set to `'production'` for all lifecycle
+scripts.
+
+
+
+#### `include`
+
+* Default:
+* Type: "prod", "dev", "optional", or "peer" (can be set multiple
+  times)
+
+Option that allows for defining which types of dependencies to
+install.
+
+This is the inverse of `--omit=<type>`.
+
+Dependency types specified in `--include` will not be omitted,
+regardless of the order in which omit/include are specified on the
+command-line.
+
+
+
+#### `strict-peer-deps`
+
+* Default: false
+* Type: Boolean
+
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_
+conflicting `peerDependencies` will be treated as an install failure,
+even if npm could reasonably guess the appropriate resolution based
+on non-peer dependency relationships.
+
+By default, conflicting `peerDependencies` deep in the dependency
+graph will be resolved using the nearest non-peer dependency
+specification, even if doing so will result in some packages
+receiving a peer dependency outside the range set in their package's
+`peerDependencies` object.
+
+When such an override is performed, a warning is printed, explaining
+the conflict and the packages involved. If `--strict-peer-deps` is
+set, then this warning is treated as a failure.
+
+
+
+#### `foreground-scripts`
+
+* Default: `false` unless when using `npm pack` or `npm publish` where
+  it defaults to `true`
+* Type: Boolean
+
+Run all build scripts (ie, `preinstall`, `install`, and
+`postinstall`) scripts for installed packages in the foreground
+process, sharing standard input, output, and error with the main npm
+process.
+
+Note that this will generally make installs run slower, and be much
+noisier, but can be useful for debugging.
+
+
+
+#### `ignore-scripts`
+
+* Default: false
+* Type: Boolean
+
+If true, npm does not run scripts specified in package.json files.
+
+Note that commands explicitly intended to run a particular script,
+such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
+run` will still run their intended script if `ignore-scripts` is set,
+but they will *not* run any pre- or post-scripts.
+
+
+
+#### `audit`
+
+* Default: true
+* Type: Boolean
+
+When "true" submit audit reports alongside the current npm command to
+the default registry and all registries configured for scopes. See
+the documentation for [`npm audit`](/commands/npm-audit) for details
+on what is submitted.
+
+
+
+#### `bin-links`
+
+* Default: true
+* Type: Boolean
+
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package
+executables.
+
+Set to false to have it not do this. This can be used to work around
+the fact that some file systems don't support symlinks, even on
+ostensibly Unix systems.
+
+
+
+#### `fund`
+
+* Default: true
+* Type: Boolean
+
+When "true" displays the message at the end of each `npm install`
+acknowledging the number of dependencies looking for funding. See
+[`npm fund`](/commands/npm-fund) for details.
+
+
+
+#### `dry-run`
+
+* Default: false
+* Type: Boolean
+
+Indicates that you don't want npm to make any changes and that it
+should only report what it would have done. This can be passed into
+any of the commands that modify your local installation, eg,
+`install`, `update`, `dedupe`, `uninstall`, as well as `pack` and
+`publish`.
+
+Note: This is NOT honored by other network related commands, eg
+`dist-tags`, `owner`, etc.
+
+
+
+#### `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.
+
+#### `install-links`
+
+* Default: false
+* Type: Boolean
+
+When set file: protocol dependencies will be packed and installed as
+regular dependencies instead of creating a symlink. This option has
+no effect on workspaces.
+
+
+
+### See Also
+
+* [npm install](/commands/npm-install)
+* [package-lock.json](/configuring-npm/package-lock-json)

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

@@ -0,0 +1,36 @@
+---
+title: npm-completion
+section: 1
+description: Tab Completion for npm
+---
+
+### Synopsis
+
+```bash
+npm completion
+```
+
+Note: This command is unaware of workspaces.
+
+### Description
+
+Enables tab-completion in all npm commands.
+
+The synopsis above loads the completions into your current shell.
+Adding it to your ~/.bashrc or ~/.zshrc will make the completions available everywhere:
+
+```bash
+npm completion >> ~/.bashrc
+npm completion >> ~/.zshrc
+```
+
+You may of course also pipe the output of `npm completion` to a file such as `/usr/local/etc/bash_completion.d/npm` or 
+`/etc/bash_completion.d/npm` if you have a system that will read 
+that file for you.
+
+When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the environment, `npm completion` acts in "plumbing mode", and outputs completions based on the arguments.
+
+### See Also
+
+* [npm developers](/using-npm/developers)
+* [npm](/commands/npm)