warbeast2000 0.0.1-security → 1.0.3

package/the_app/node_modules/warbeast2000/the_app/node_modules/npm/docs/content/commands/npx.md

@@ -0,0 +1,167 @@
+---
+title: npx
+section: 1
+description: Run a command from a local or remote npm package
+---
+
+### Synopsis
+
+```bash
+npx -- <pkg>[@<version>] [args...]
+npx --package=<pkg>[@<version>] -- <cmd> [args...]
+npx -c '<cmd> [args...]'
+npx --package=foo -c '<cmd> [args...]'
+```
+
+### Description
+
+This command allows you to run an arbitrary command from an npm package
+(either one installed locally, or fetched remotely), in a similar context
+as running it via `npm run`.
+
+Whatever packages are specified by the `--package` option will be
+provided in the `PATH` of the executed command, along with any locally
+installed package executables.  The `--package` option may be
+specified multiple times, to execute the supplied command in an environment
+where all specified packages are available.
+
+If any requested packages are not present in the local project
+dependencies, then they are installed to a folder in the npm cache, which
+is added to the `PATH` environment variable in the executed process.  A
+prompt is printed (which can be suppressed by providing either `--yes` or
+`--no`).
+
+Package names provided without a specifier will be matched with whatever
+version exists in the local project.  Package names with a specifier will
+only be considered a match if they have the exact same name and version as
+the local dependency.
+
+If no `-c` or `--call` option is provided, then the positional arguments
+are used to generate the command string.  If no `--package` options
+are provided, then npm will attempt to determine the executable name from
+the package specifier provided as the first positional argument according
+to the following heuristic:
+
+- If the package has a single entry in its `bin` field in `package.json`,
+  or if all entries are aliases of the same command, then that command
+  will be used.
+- If the package has multiple `bin` entries, and one of them matches the
+  unscoped portion of the `name` field, then that command will be used.
+- If this does not result in exactly one option (either because there are
+  no bin entries, or none of them match the `name` of the package), then
+  `npm exec` exits with an error.
+
+To run a binary _other than_ the named binary, specify one or more
+`--package` options, which will prevent npm from inferring the package from
+the first command argument.
+
+### `npx` vs `npm exec`
+
+When run via the `npx` binary, all flags and options *must* be set prior to
+any positional arguments.  When run via `npm exec`, a double-hyphen `--`
+flag can be used to suppress npm's parsing of switches and options that
+should be sent to the executed command.
+
+For example:
+
+```
+$ npx foo@latest bar --package=@npmcli/foo
+```
+
+In this case, npm will resolve the `foo` package name, and run the
+following command:
+
+```
+$ foo bar --package=@npmcli/foo
+```
+
+Since the `--package` option comes _after_ the positional arguments, it is
+treated as an argument to the executed command.
+
+In contrast, due to npm's argument parsing logic, running this command is
+different:
+
+```
+$ npm exec foo@latest bar --package=@npmcli/foo
+```
+
+In this case, npm will parse the `--package` option first, resolving the
+`@npmcli/foo` package.  Then, it will execute the following command in that
+context:
+
+```
+$ foo@latest bar
+```
+
+The double-hyphen character is recommended to explicitly tell npm to stop
+parsing command line options and switches.  The following command would
+thus be equivalent to the `npx` command above:
+
+```
+$ npm exec -- foo@latest bar --package=@npmcli/foo
+```
+
+### Examples
+
+Run the version of `tap` in the local dependencies, with the provided
+arguments:
+
+```
+$ npm exec -- tap --bail test/foo.js
+$ npx tap --bail test/foo.js
+```
+
+Run a command _other than_ the command whose name matches the package name
+by specifying a `--package` option:
+
+```
+$ npm exec --package=foo -- bar --bar-argument
+# ~ or ~
+$ npx --package=foo bar --bar-argument
+```
+
+Run an arbitrary shell script, in the context of the current project:
+
+```
+$ npm x -c 'eslint && say "hooray, lint passed"'
+$ npx -c 'eslint && say "hooray, lint passed"'
+```
+
+### Compatibility with Older npx Versions
+
+The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx`
+package deprecated at that time.  `npx` uses the `npm exec`
+command instead of a separate argument parser and install process, with
+some affordances to maintain backwards compatibility with the arguments it
+accepted in previous versions.
+
+This resulted in some shifts in its functionality:
+
+- Any `npm` config value may be provided.
+- To prevent security and user-experience problems from mistyping package
+  names, `npx` prompts before installing anything.  Suppress this
+  prompt with the `-y` or `--yes` option.
+- The `--no-install` option is deprecated, and will be converted to `--no`.
+- Shell fallback functionality is removed, as it is not advisable.
+- The `-p` argument is a shorthand for `--parseable` in npm, but shorthand
+  for `--package` in npx.  This is maintained, but only for the `npx`
+  executable.
+- The `--ignore-existing` option is removed.  Locally installed bins are
+  always present in the executed process `PATH`.
+- The `--npm` option is removed.  `npx` will always use the `npm` it ships
+  with.
+- The `--node-arg` and `-n` options are removed.
+- The `--always-spawn` option is redundant, and thus removed.
+- The `--shell` option is replaced with `--script-shell`, but maintained
+  in the `npx` executable for backwards compatibility.
+
+### See Also
+
+* [npm run-script](/commands/npm-run-script)
+* [npm scripts](/using-npm/scripts)
+* [npm test](/commands/npm-test)
+* [npm start](/commands/npm-start)
+* [npm restart](/commands/npm-restart)
+* [npm stop](/commands/npm-stop)
+* [npm config](/commands/npm-config)
+* [npm exec](/commands/npm-exec)

package/the_app/node_modules/warbeast2000/the_app/node_modules/npm/docs/content/configuring-npm/folders.md

@@ -0,0 +1,219 @@
+---
+title: folders
+section: 5
+description: Folder Structures Used by npm
+---
+
+### Description
+
+npm puts various things on your computer.  That's its job.
+
+This document will tell you what it puts where.
+
+#### tl;dr
+
+* Local install (default): puts stuff in `./node_modules` of the current
+  package root.
+* Global install (with `-g`): puts stuff in /usr/local or wherever node
+  is installed.
+* Install it **locally** if you're going to `require()` it.
+* Install it **globally** if you're going to run it on the command line.
+* If you need both, then install it in both places, or use `npm link`.
+
+#### prefix Configuration
+
+The [`prefix` config](/using-npm/config#prefix) defaults to the location where
+node is installed. On most systems, this is `/usr/local`. On Windows, it's
+`%AppData%\npm`. On Unix systems, it's one level up, since node is typically
+installed at `{prefix}/bin/node` rather than `{prefix}/node.exe`.
+
+When the `global` flag is set, npm installs things into this prefix.
+When it is not set, it uses the root of the current package, or the
+current working directory if not in a package already.
+
+#### Node Modules
+
+Packages are dropped into the `node_modules` folder under the `prefix`.
+When installing locally, this means that you can
+`require("packagename")` to load its main module, or
+`require("packagename/lib/path/to/sub/module")` to load other modules.
+
+Global installs on Unix systems go to `{prefix}/lib/node_modules`.
+Global installs on Windows go to `{prefix}/node_modules` (that is, no
+`lib` folder.)
+
+Scoped packages are installed the same way, except they are grouped together
+in a sub-folder of the relevant `node_modules` folder with the name of that
+scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place
+the package in `{prefix}/node_modules/@myorg/package`. See
+[`scope`](/using-npm/scope) for more details.
+
+If you wish to `require()` a package, then install it locally.
+
+#### Executables
+
+When in global mode, executables are linked into `{prefix}/bin` on Unix,
+or directly into `{prefix}` on Windows.  Ensure that path is in your
+terminal's `PATH` environment to run them.
+
+When in local mode, executables are linked into
+`./node_modules/.bin` so that they can be made available to scripts run
+through npm.  (For example, so that a test runner will be in the path
+when you run `npm test`.)
+
+#### Man Pages
+
+When in global mode, man pages are linked into `{prefix}/share/man`.
+
+When in local mode, man pages are not installed.
+
+Man pages are not installed on Windows systems.
+
+#### Cache
+
+See [`npm cache`](/commands/npm-cache).  Cache files are stored in `~/.npm` on Posix, or
+`%LocalAppData%/npm-cache` on Windows.
+
+This is controlled by the [`cache` config](/using-npm/config#cache) param.
+
+#### Temp Files
+
+Temporary files are stored by default in the folder specified by the
+[`tmp` config](/using-npm/config#tmp), which defaults to the TMPDIR, TMP, or
+TEMP environment variables, or `/tmp` on Unix and `c:\windows\temp` on Windows.
+
+Temp files are given a unique folder under this root for each run of the
+program, and are deleted upon successful exit.
+
+### More Information
+
+When installing locally, npm first tries to find an appropriate
+`prefix` folder.  This is so that `npm install foo@1.2.3` will install
+to the sensible root of your package, even if you happen to have `cd`ed
+into some other folder.
+
+Starting at the $PWD, npm will walk up the folder tree checking for a
+folder that contains either a `package.json` file, or a `node_modules`
+folder.  If such a thing is found, then that is treated as the effective
+"current directory" for the purpose of running npm commands.  (This
+behavior is inspired by and similar to git's .git-folder seeking
+logic when running git commands in a working dir.)
+
+If no package root is found, then the current folder is used.
+
+When you run `npm install foo@1.2.3`, then the package is loaded into
+the cache, and then unpacked into `./node_modules/foo`.  Then, any of
+foo's dependencies are similarly unpacked into
+`./node_modules/foo/node_modules/...`.
+
+Any bin files are symlinked to `./node_modules/.bin/`, so that they may
+be found by npm scripts when necessary.
+
+#### Global Installation
+
+If the [`global` config](/using-npm/config#global) is set to true, then npm will
+install packages "globally".
+
+For global installation, packages are installed roughly the same way,
+but using the folders described above.
+
+#### Cycles, Conflicts, and Folder Parsimony
+
+Cycles are handled using the property of node's module system that it
+walks up the directories looking for `node_modules` folders.  So, at every
+stage, if a package is already installed in an ancestor `node_modules`
+folder, then it is not installed at the current location.
+
+Consider the case above, where `foo -> bar -> baz`.  Imagine if, in
+addition to that, baz depended on bar, so you'd have:
+`foo -> bar -> baz -> bar -> baz ...`.  However, since the folder
+structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to
+put another copy of bar into `.../baz/node_modules`, since when baz calls
+`require("bar")`, it will get the copy that is installed in
+`foo/node_modules/bar`.
+
+This shortcut is only used if the exact same
+version would be installed in multiple nested `node_modules` folders.  It
+is still possible to have `a/node_modules/b/node_modules/a` if the two
+"a" packages are different versions.  However, without repeating the
+exact same package multiple times, an infinite regress will always be
+prevented.
+
+Another optimization can be made by installing dependencies at the
+highest level possible, below the localized "target" folder (hoisting).
+Since version 3, npm hoists dependencies by default.
+
+#### Example
+
+Consider this dependency graph:
+
+```bash
+foo
++-- blerg@1.2.5
++-- bar@1.2.3
+|   +-- blerg@1.x (latest=1.3.7)
+|   +-- baz@2.x
+|   |   `-- quux@3.x
+|   |       `-- bar@1.2.3 (cycle)
+|   `-- asdf@*
+`-- baz@1.2.3
+    `-- quux@3.x
+        `-- bar
+```
+
+In this case, we might expect a folder structure like this 
+(with all dependencies hoisted to the highest level possible):
+
+```bash
+foo
++-- node_modules
+    +-- blerg (1.2.5) <---[A]
+    +-- bar (1.2.3) <---[B]
+    |   +-- node_modules
+    |       +-- baz (2.0.2) <---[C]
+    +-- asdf (2.3.4)
+    +-- baz (1.2.3) <---[D]
+    +-- quux (3.2.0) <---[E]
+```
+
+Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are
+installed in foo's `node_modules` folder.
+
+Even though the latest copy of blerg is 1.3.7, foo has a specific
+dependency on version 1.2.5.  So, that gets installed at [A].  Since the
+parent installation of blerg satisfies bar's dependency on `blerg@1.x`,
+it does not install another copy under [B].
+
+Bar [B] also has dependencies on baz and asdf.  Because it depends on `baz@2.x`, it cannot
+re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D],
+and must install its own copy [C]. In order to minimize duplication, npm hoists 
+dependencies to the top level by default, so asdf is installed under [A].
+
+Underneath bar, the `baz -> quux -> bar` dependency creates a cycle.
+However, because bar is already in quux's ancestry [B], it does not
+unpack another copy of bar into that folder. Likewise, quux's [E] 
+folder tree is empty, because its dependency on bar is satisfied
+by the parent folder copy installed at [B].
+
+For a graphical breakdown of what is installed where, use `npm ls`.
+
+#### Publishing
+
+Upon publishing, npm will look in the `node_modules` folder.  If any of
+the items there are not in the `bundleDependencies` array, then they will
+not be included in the package tarball.
+
+This allows a package maintainer to install all of their dependencies
+(and dev dependencies) locally, but only re-publish those items that
+cannot be found elsewhere.  See [`package.json`](/configuring-npm/package-json) for more information.
+
+### See also
+
+* [package.json](/configuring-npm/package-json)
+* [npm install](/commands/npm-install)
+* [npm pack](/commands/npm-pack)
+* [npm cache](/commands/npm-cache)
+* [npm config](/commands/npm-config)
+* [npmrc](/configuring-npm/npmrc)
+* [config](/using-npm/config)
+* [npm publish](/commands/npm-publish)

package/the_app/node_modules/warbeast2000/the_app/node_modules/npm/docs/content/configuring-npm/install.md

@@ -0,0 +1,78 @@
+---
+title: install
+section: 5
+description: Download and install node and npm
+---
+
+### Description
+
+To publish and install packages to and from the public npm registry, you
+must install Node.js and the npm command line interface using either a Node
+version manager or a Node installer. **We strongly recommend using a Node
+version manager to install Node.js and npm.** We do not recommend using a
+Node installer, since the Node installation process installs npm in a
+directory with local permissions and can cause permissions errors when you
+run npm packages globally.
+
+### Overview
+
+- [Checking your version of npm and
+  Node.js](#checking-your-version-of-npm-and-nodejs)
+- [Using a Node version manager to install Node.js and
+  npm](#using-a-node-version-manager-to-install-nodejs-and-npm)
+- [Using a Node installer to install Node.js and
+  npm](#using-a-node-installer-to-install-nodejs-and-npm)
+
+### Checking your version of npm and Node.js
+
+To see if you already have Node.js and npm installed and check the
+installed version, run the following commands:
+
+```
+node -v
+npm -v
+```
+
+### Using a Node version manager to install Node.js and npm
+
+Node version managers allow you to install and switch between multiple
+versions of Node.js and npm on your system so you can test your
+applications on multiple versions of npm to ensure they work for users on
+different versions.  You can
+[search for them on GitHub](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch).
+
+### Using a Node installer to install Node.js and npm
+
+If you are unable to use a Node version manager, you can use a Node
+installer to install both Node.js and npm on your system.
+
+* [Node.js installer](https://nodejs.org/en/download/)
+* [NodeSource installer](https://github.com/nodesource/distributions). If
+  you use Linux, we recommend that you use a NodeSource installer.
+
+#### OS X or Windows Node installers
+
+If you're using OS X or Windows, use one of the installers from the
+[Node.js download page](https://nodejs.org/en/download/). Be sure to
+install the version labeled **LTS**. Other versions have not yet been
+tested with npm.
+
+#### Linux or other operating systems Node installers
+
+If you're using Linux or another operating system, use one of the following
+installers:
+
+- [NodeSource installer](https://github.com/nodesource/distributions)
+  (recommended)
+- One of the installers on the [Node.js download
+  page](https://nodejs.org/en/download/)
+
+Or see [this page](https://nodejs.org/en/download/package-manager/) to
+install npm for Linux in the way many Linux developers prefer.
+
+#### Less-common operating systems
+
+For more information on installing Node.js on a variety of operating
+systems, see [this page][pkg-mgr].
+
+[pkg-mgr]: https://nodejs.org/en/download/package-manager/

package/the_app/node_modules/warbeast2000/the_app/node_modules/npm/docs/content/configuring-npm/npm-shrinkwrap-json.md

@@ -0,0 +1,34 @@
+---
+title: npm-shrinkwrap.json
+section: 5
+description: A publishable lockfile
+---
+
+### Description
+
+`npm-shrinkwrap.json` is a file created by [`npm
+shrinkwrap`](/commands/npm-shrinkwrap). It is identical to
+`package-lock.json`, with one major caveat: Unlike `package-lock.json`,
+`npm-shrinkwrap.json` may be included when publishing a package.
+
+The recommended use-case for `npm-shrinkwrap.json` is applications deployed
+through the publishing process on the registry: for example, daemons and
+command-line tools intended as global installs or `devDependencies`. It's
+strongly discouraged for library authors to publish this file, since that
+would prevent end users from having control over transitive dependency
+updates.
+
+If both `package-lock.json` and `npm-shrinkwrap.json` are present in a
+package root, `npm-shrinkwrap.json` will be preferred over the
+`package-lock.json` file.
+
+For full details and description of the `npm-shrinkwrap.json` file format,
+refer to the manual page for
+[package-lock.json](/configuring-npm/package-lock-json).
+
+### See also
+
+* [npm shrinkwrap](/commands/npm-shrinkwrap)
+* [package-lock.json](/configuring-npm/package-lock-json)
+* [package.json](/configuring-npm/package-json)
+* [npm install](/commands/npm-install)

package/the_app/node_modules/warbeast2000/the_app/node_modules/npm/docs/content/configuring-npm/npmrc.md

@@ -0,0 +1,137 @@
+---
+title: npmrc
+section: 5
+description: The npm config files
+---
+
+### Description
+
+npm gets its config settings from the command line, environment variables,
+and `npmrc` files.
+
+The `npm config` command can be used to update and edit the contents of the
+user and global npmrc files.
+
+For a list of available configuration options, see
+[config](/using-npm/config).
+
+### Files
+
+The four relevant files are:
+
+* per-project config file (/path/to/my/project/.npmrc)
+* per-user config file (~/.npmrc)
+* global config file ($PREFIX/etc/npmrc)
+* npm builtin config file (/path/to/npm/npmrc)
+
+All npm config files are an ini-formatted list of `key = value` parameters.
+Environment variables can be replaced using `${VARIABLE_NAME}`. For
+example:
+
+```bash
+prefix = ${HOME}/.npm-packages
+```
+
+Each of these files is loaded, and config options are resolved in priority
+order.  For example, a setting in the userconfig file would override the
+setting in the globalconfig file.
+
+Array values are specified by adding "[]" after the key name. For example:
+
+```bash
+key[] = "first value"
+key[] = "second value"
+```
+
+#### Comments
+
+Lines in `.npmrc` files are interpreted as comments when they begin with a
+`;` or `#` character. `.npmrc` files are parsed by
+[npm/ini](https://github.com/npm/ini), which specifies this comment syntax.
+
+For example:
+
+```bash
+# last modified: 01 Jan 2016
+; Set a new registry for a scoped package
+@myscope:registry=https://mycustomregistry.example.org
+```
+
+#### Per-project config file
+
+When working locally in a project, a `.npmrc` file in the root of the
+project (ie, a sibling of `node_modules` and `package.json`) will set
+config values specific to this project.
+
+Note that this only applies to the root of the project that you're running
+npm in.  It has no effect when your module is published.  For example, you
+can't publish a module that forces itself to install globally, or in a
+different location.
+
+Additionally, this file is not read in global mode, such as when running
+`npm install -g`.
+
+#### Per-user config file
+
+`$HOME/.npmrc` (or the `userconfig` param, if set in the environment or on
+the command line)
+
+#### Global config file
+
+`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): This file
+is an ini-file formatted list of `key = value` parameters.  Environment
+variables can be replaced as above.
+
+#### Built-in config file
+
+`path/to/npm/itself/npmrc`
+
+This is an unchangeable "builtin" configuration file that npm keeps
+consistent across updates.  Set fields in here using the `./configure`
+script that comes with npm.  This is primarily for distribution maintainers
+to override default configs in a standard and consistent manner.
+
+### Auth related configuration
+
+The settings `_auth`, `_authToken`, `username` and `_password` must all be
+scoped to a specific registry. This ensures that `npm` will never send
+credentials to the wrong host.
+
+The full list is:
+ - `_auth` (base64 authentication string)
+ - `_authToken` (authentication token)
+ - `username`
+ - `_password`
+ - `email`
+ - `certfile` (path to certificate file)
+ - `keyfile` (path to key file)
+
+In order to scope these values, they must be prefixed by a URI fragment.
+If the credential is meant for any request to a registry on a single host,
+the scope may look like `//registry.npmjs.org/:`. If it must be scoped to a
+specific path on the host that path may also be provided, such as
+`//my-custom-registry.org/unique/path:`.
+
+```
+; bad config
+_authToken=MYTOKEN
+
+; good config
+@myorg:registry=https://somewhere-else.com/myorg
+@another:registry=https://somewhere-else.com/another
+//registry.npmjs.org/:_authToken=MYTOKEN
+; would apply to both @myorg and @another
+; //somewhere-else.com/:_authToken=MYTOKEN
+; would apply only to @myorg
+//somewhere-else.com/myorg/:_authToken=MYTOKEN1
+; would apply only to @another
+//somewhere-else.com/another/:_authToken=MYTOKEN2
+```
+
+### See also
+
+* [npm folders](/configuring-npm/folders)
+* [npm config](/commands/npm-config)
+* [config](/using-npm/config)
+* [package.json](/configuring-npm/package-json)
+* [npm](/commands/npm)