@patternfly-java/charts 0.0.1 → 0.0.2

package/node/node_modules/npm/docs/content/commands/npx.md

@@ -1,168 +0,0 @@
----
-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 have been removed. Use [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) instead: e.g.,
- `NODE_OPTIONS="--trace-warnings --trace-exit" npx foo --random=true`
-- 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](/commands/npm-run)
-* [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/node/node_modules/npm/docs/content/configuring-npm/folders.md

@@ -1,210 +0,0 @@
----
-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.
-
-### 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/node/node_modules/npm/docs/content/configuring-npm/install.md

@@ -1,71 +0,0 @@
----
-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.
-
-#### macOS or Windows Node installers
-
-If you're using macOS 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.

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

@@ -1,34 +0,0 @@
----
-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/node/node_modules/npm/docs/content/configuring-npm/npmrc.md

@@ -1,144 +0,0 @@
----
-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}`. By default
-if the variable is not defined, it is left unreplaced. By adding `?` after
-variable name they can be forced to evaluate to an empty string instead. For
-example:
-
-```bash
-cache = ${HOME}/.npm-packages
-node-options = "${NODE_OPTIONS?} --use-system-ca"
-```
-
-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`, `_password`, `certfile`,
-and `keyfile` 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`
- - `cafile` (path to certificate authority file)
- - `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)