fca-rqzax-remake 0.0.1-security → 8.19.2

package/.config/npm/node_global/lib/node_modules/npm/docs/content/commands/npm-bugs.md

@@ -0,0 +1,105 @@
+---
+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: OS X: `"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/.config/npm/node_global/lib/node_modules/npm/docs/content/commands/npm-cache.md

@@ -0,0 +1,92 @@
+---
+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
+```
+
+Note: This command is unaware of workspaces.
+
+### Description
+
+Used to add, list, or clean the npm cache folder.
+
+* 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 all data out of the cache folder.  Note that this is typically
+  unnecessary, as npm's cache is self-healing and resistant to data
+  corruption issues.
+
+* 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.
+
+### 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)
+* https://npm.im/cacache
+* https://npm.im/pacote
+* https://npm.im/@npmcli/arborist
+* https://npm.im/make-fetch-happen

package/.config/npm/node_global/lib/node_modules/npm/docs/content/commands/npm-ci.md

@@ -0,0 +1,323 @@
+---
+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
+
+#### `save`
+
+* Default: `true` unless when using `npm update` where it defaults to `false`
+* Type: Boolean
+
+Save installed packages to a `package.json` file as dependencies.
+
+When used with the `npm rm` command, removes the dependency from
+`package.json`.
+
+Will also prevent writing to `package-lock.json` if set to `false`.
+
+#### `save-exact`
+
+* Default: false
+* Type: Boolean
+
+Dependencies saved to package.json will be configured with an exact version
+rather than using npm's default semver range operator.
+
+#### `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`
+
+#### `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.
+
+#### `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.
+
+#### `package-lock`
+
+* Default: true
+* Type: Boolean
+
+If set to false, then ignore `package-lock.json` files when installing. This
+will also prevent _writing_ `package-lock.json` if `save` is true.
+
+This configuration does not affect `npm ci`.
+
+#### `foreground-scripts`
+
+* Default: false
+* 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-script`
+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/.config/npm/node_global/lib/node_modules/npm/docs/content/commands/npm-completion.md

@@ -0,0 +1,41 @@
+---
+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)