@patternfly-java/charts 0.0.1 → 0.0.3

package/node/node_modules/npm/docs/content/commands/npm-diff.md

@@ -1,319 +0,0 @@
----
-title: npm-diff
-section: 1
-description: The registry diff command
----
-
-### Synopsis
-
-```bash
-npm diff [...<paths>]
-```
-
-### Description
-
-Similar to its `git diff` counterpart, this command will print diff patches
-of files for packages published to the npm registry.
-
-* `npm diff --diff=<spec-a> --diff=<spec-b>`
-
-    Compares two package versions using their registry specifiers, e.g:
-    `npm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0`. It's also possible to
-    compare across forks of any package,
-    e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0`.
-
-    Any valid spec can be used, so that it's also possible to compare
-    directories or git repositories,
-    e.g: `npm diff --diff=pkg@latest --diff=./packages/pkg`
-
-    Here's an example comparing two different versions of a package named
-    `abbrev` from the registry:
-
-    ```bash
-    npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
-    ```
-
-    On success, output looks like:
-
-    ```bash
-    diff --git a/package.json b/package.json
-    index v1.1.0..v1.1.1 100644
-    --- a/package.json
-    +++ b/package.json
-    @@ -1,6 +1,6 @@
-     {
-       "name": "abbrev",
-    -  "version": "1.1.0",
-    +  "version": "1.1.1",
-       "description": "Like ruby's abbrev module, but in js",
-       "author": "Isaac Z. Schlueter <i@izs.me>",
-       "main": "abbrev.js",
-    ```
-
-    Given the flexible nature of npm specs, you can also target local
-    directories or git repos just like when using `npm install`:
-
-    ```bash
-    npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
-    ```
-
-    In the example above we can compare the contents from the package installed
-    from the git repo at `github.com/npm/libnpmdiff` with the contents of the
-    `./local-path` that contains a valid package, such as a modified copy of
-    the original.
-
-* `npm diff` (in a package directory, no arguments):
-
-    If the package is published to the registry, `npm diff` will fetch the
-    tarball version tagged as `latest` (this value can be configured using the
-    `tag` option) and proceed to compare the contents of files present in that
-    tarball, with the current files in your local file system.
-
-    This workflow provides a handy way for package authors to see what
-    package-tracked files have been changed in comparison with the latest
-    published version of that package.
-
-* `npm diff --diff=<pkg-name>` (in a package directory):
-
-    When using a single package name (with no version or tag specifier) as an
-    argument, `npm diff` will work in a similar way to
-    [`npm-outdated`](npm-outdated) and reach for the registry to figure out
-    what current published version of the package named `<pkg-name>`
-    will satisfy its dependent declared semver-range. Once that specific
-    version is known `npm diff` will print diff patches comparing the
-    current version of `<pkg-name>` found in the local file system with
-    that specific version returned by the registry.
-
-    Given a package named `abbrev` that is currently installed:
-
-    ```bash
-    npm diff --diff=abbrev
-    ```
-
-    That will request from the registry its most up to date version and
-    will print a diff output comparing the currently installed version to this
-    newer one if the version numbers are not the same.
-
-* `npm diff --diff=<spec-a>` (in a package directory):
-
-    Similar to using only a single package name, it's also possible to declare
-    a full registry specifier version if you wish to compare the local version
-    of an installed package with the specific version/tag/semver-range provided
-    in `<spec-a>`.
-
-    An example: assuming `pkg@1.0.0` is installed in the current `node_modules`
-    folder, running:
-
-    ```bash
-    npm diff --diff=pkg@2.0.0
-    ```
-
-    It will effectively be an alias to
-    `npm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0`.
-
-* `npm diff --diff=<semver-a> [--diff=<semver-b>]` (in a package directory):
-
-    Using `npm diff` along with semver-valid version numbers is a shorthand
-    to compare different versions of the current package.
-
-    It needs to be run from a package directory, such that for a package named
-    `pkg` running `npm diff --diff=1.0.0 --diff=1.0.1` is the same as running
-    `npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1`.
-
-    If only a single argument `<version-a>` is provided, then the current local
-    file system is going to be compared against that version.
-
-    Here's an example comparing two specific versions (published to the
-    configured registry) of the current project directory:
-
-    ```bash
-    npm diff --diff=1.0.0 --diff=1.1.0
-    ```
-
-Note that tag names are not valid `--diff` argument values, if you wish to
-compare to a published tag, you must use the `pkg@tagname` syntax.
-
-#### Filtering files
-
-It's possible to also specify positional arguments using file names or globs
-pattern matching in order to limit the result of diff patches to only a subset
-of files for a given package, e.g:
-
-  ```bash
-  npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
-  ```
-
-In the example above the diff output is only going to print contents of files
-located within the folder `./lib/` and changed lines of code within the
-`CHANGELOG.md` file.
-
-### Configuration
-
-#### `diff`
-
-* Default:
-* Type: String (can be set multiple times)
-
-Define arguments to compare in `npm diff`.
-
-
-
-#### `diff-name-only`
-
-* Default: false
-* Type: Boolean
-
-Prints only filenames when using `npm diff`.
-
-
-
-#### `diff-unified`
-
-* Default: 3
-* Type: Number
-
-The number of lines of context to print in `npm diff`.
-
-
-
-#### `diff-ignore-all-space`
-
-* Default: false
-* Type: Boolean
-
-Ignore whitespace when comparing lines in `npm diff`.
-
-
-
-#### `diff-no-prefix`
-
-* Default: false
-* Type: Boolean
-
-Do not show any source or destination prefix in `npm diff` output.
-
-Note: this causes `npm diff` to ignore the `--diff-src-prefix` and
-`--diff-dst-prefix` configs.
-
-
-
-#### `diff-src-prefix`
-
-* Default: "a/"
-* Type: String
-
-Source prefix to be used in `npm diff` output.
-
-
-
-#### `diff-dst-prefix`
-
-* Default: "b/"
-* Type: String
-
-Destination prefix to be used in `npm diff` output.
-
-
-
-#### `diff-text`
-
-* Default: false
-* Type: Boolean
-
-Treat all files as text in `npm diff`.
-
-
-
-#### `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`
-
-
-
-#### `tag`
-
-* Default: "latest"
-* Type: String
-
-If you ask npm to install a package and don't tell it a specific version,
-then it will install the specified tag.
-
-It is the tag added to the package@version specified in the `npm dist-tag
-add` command, if no explicit tag is given.
-
-When used by the `npm diff` command, this is the tag used to fetch the
-tarball that will be compared with the local files by default.
-
-If used in the `npm publish` command, this is the tag that will be added to
-the package submitted to the 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 outdated](/commands/npm-outdated)
-* [npm install](/commands/npm-install)
-* [npm config](/commands/npm-config)
-* [npm registry](/using-npm/registry)

package/node/node_modules/npm/docs/content/commands/npm-dist-tag.md

@@ -1,154 +0,0 @@
----
-title: npm-dist-tag
-section: 1
-description: Modify package distribution tags
----
-
-### Synopsis
-
-```bash
-npm dist-tag add <package-spec (with version)> [<tag>]
-npm dist-tag rm <package-spec> <tag>
-npm dist-tag ls [<package-spec>]
-
-alias: dist-tags
-```
-
-### Description
-
-Add, remove, and enumerate distribution tags on a package:
-
-* add: Tags the specified version of the package with the specified tag,
-  or the [`--tag` config](/using-npm/config#tag) if not specified. If you have
-  two-factor authentication on auth-and-writes then you’ll need to include a
-  one-time password on the command line with
-  `--otp <one-time password>`, or go through a second factor flow based on your `authtype`.
-
-* rm: Clear a tag that is no longer in use from the package. If you have
-  two-factor authentication on auth-and-writes then you’ll need to include
-  a one-time password on the command line with `--otp <one-time password>`,
-  or go through a second factor flow based on your `authtype`
-
-* ls: Show all of the dist-tags for a package, defaulting to the package in
-  the current prefix. This is the default action if none is specified.
-
-A tag can be used when installing packages as a reference to a version instead
-of using a specific version number:
-
-```bash
-npm install <name>@<tag>
-```
-
-When installing dependencies, a preferred tagged version may be specified:
-
-```bash
-npm install --tag <tag>
-```
-
-(This also applies to any other commands that resolve and install
-dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.)
-
-Publishing a package sets the `latest` tag to the published version unless the
-`--tag` option is used. For example, `npm publish --tag=beta`.
-
-By default, `npm install <pkg>` (without any `@<version>` or `@<tag>`
-specifier) installs the `latest` tag.
-
-### Purpose
-
-Tags can be used to provide an alias instead of version numbers.
-
-For example, a project might choose to have multiple streams of development
-and use a different tag for each stream, e.g., `stable`, `beta`, `dev`,
-`canary`.
-
-By default, the `latest` tag is used by npm to identify the current version
-of a package, and `npm install <pkg>` (without any `@<version>` or `@<tag>`
-specifier) installs the `latest` tag. Typically, projects only use the
-`latest` tag for stable release versions, and use other tags for unstable
-versions such as prereleases.
-
-The `next` tag is used by some projects to identify the upcoming version.
-
-Other than `latest`, no tag has any special significance to npm itself.
-
-### Caveats
-
-This command used to be known as `npm tag`, which only created new tags,
-and so had a different syntax.
-
-Tags must share a namespace with version numbers, because they are
-specified in the same slot: `npm install <pkg>@<version>` vs
-`npm install <pkg>@<tag>`.
-
-Tags that can be interpreted as valid semver ranges will be rejected. For
-example, `v1.4` cannot be used as a tag, because it is interpreted by
-semver as `>=1.4.0 <1.5.0`.  See <https://github.com/npm/npm/issues/6082>.
-
-The simplest way to avoid semver problems with tags is to use tags that do
-not begin with a number or the letter `v`.
-
-### Configuration
-
-#### `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
-
-* [package spec](/using-npm/package-spec)
-* [npm publish](/commands/npm-publish)
-* [npm install](/commands/npm-install)
-* [npm dedupe](/commands/npm-dedupe)
-* [npm registry](/using-npm/registry)
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)

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

@@ -1,108 +0,0 @@
----
-title: npm-docs
-section: 1
-description: Open documentation for a package in a web browser
----
-
-### Synopsis
-
-```bash
-npm docs [<pkgname> [<pkgname> ...]]
-
-alias: home
-```
-
-### Description
-
-This command tries to guess at the likely location of a package's
-documentation URL, and then tries to open it using the
-[`--browser` config](/using-npm/config#browser) param. You can pass multiple
-package names at once. 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 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/node/node_modules/npm/docs/content/commands/npm-doctor.md

@@ -1,123 +0,0 @@
----
-title: npm-doctor
-section: 1
-description: Check the health of your npm environment
----
-
-### Synopsis
-
-```bash
-npm doctor [connection] [registry] [versions] [environment] [permissions] [cache]
-```
-
-Note: This command is unaware of workspaces.
-
-### Description
-
-`npm doctor` runs a set of checks to ensure that your npm installation has
-what it needs to manage your JavaScript packages. npm is mostly a
-standalone tool, but it does have some basic requirements that must be met:
-
-+ Node.js and git must be executable by npm.
-+ The primary npm registry, `registry.npmjs.com`, or another service that
-  uses the registry API, is available.
-+ The directories that npm uses, `node_modules` (both locally and
-  globally), exist and can be written by the current user.
-+ The npm cache exists, and the package tarballs within it aren't corrupt.
-
-Without all of these working properly, npm may not work properly.  Many
-issues are often attributable to things that are outside npm's code base,
-so `npm doctor` confirms that the npm installation is in a good state.
-
-Also, in addition to this, there are also very many issue reports due to
-using old versions of npm. Since npm is constantly improving, running
-`npm@latest` is better than an old version.
-
-`npm doctor` verifies the following items in your environment, and if
-there are any recommended changes, it will display them.  By default npm
-runs all of these checks. You can limit what checks are ran by
-specifying them as extra arguments.
-
-#### `Connecting to the registry`
-
-By default, npm installs from the primary npm registry,
-`registry.npmjs.org`.  `npm doctor` hits a special connection testing
-endpoint within the registry. This can also be checked with `npm ping`.
-If this check fails, you may be using a proxy that needs to be
-configured, or may need to talk to your IT staff to get access over
-HTTPS to `registry.npmjs.org`.
-
-This check is done against whichever registry you've configured (you can
-see what that is by running `npm config get registry`), and if you're using
-a private registry that doesn't support the `/whoami` endpoint supported by
-the primary registry, this check may fail.
-
-#### `Checking npm version`
-
-While Node.js may come bundled with a particular version of npm, it's the
-policy of the CLI team that we recommend all users run `npm@latest` if they
-can. As the CLI is maintained by a small team of contributors, there are
-only resources for a single line of development, so npm's own long-term
-support releases typically only receive critical security and regression
-fixes. The team believes that the latest tested version of npm is almost
-always likely to be the most functional and defect-free version of npm.
-
-#### `Checking node version`
-
-For most users, in most circumstances, the best version of Node will be the
-latest long-term support (LTS) release. Those of you who want access to new
-ECMAscript features or bleeding-edge changes to Node's standard library may
-be running a newer version, and some may be required to run an older
-version of Node because of enterprise change control policies. That's OK!
-But in general, the npm team recommends that most users run Node.js LTS.
-
-#### `Checking configured npm registry`
-
-You may be installing from private package registries for your project or
-company. That's great! Others may be following tutorials or StackOverflow
-questions in an effort to troubleshoot problems you may be having.
-Sometimes, this may entail changing the registry you're pointing at.  This
-part of `npm doctor` just lets you, and maybe whoever's helping you with
-support, know that you're not using the default registry.
-
-#### `Checking for git executable in PATH`
-
-While it's documented in the README, it may not be obvious that npm needs
-Git installed to do many of the things that it does. Also, in some cases
-– especially on Windows – you may have Git set up in such a way that it's
-not accessible via your `PATH` so that npm can find it. This check ensures
-that Git is available.
-
-#### Permissions checks
-
-* Your cache must be readable and writable by the user running npm.
-* Global package binaries must be writable by the user running npm.
-* Your local `node_modules` path, if you're running `npm doctor` with a
-  project directory, must be readable and writable by the user running npm.
-
-#### Validate the checksums of cached packages
-
-When an npm package is published, the publishing process generates a
-checksum that npm uses at install time to verify that the package didn't
-get corrupted in transit. `npm doctor` uses these checksums to validate the
-package tarballs in your local cache (you can see where that cache is
-located with `npm config get cache`). In the event that there are corrupt
-packages in your cache, you should probably run `npm cache clean -f` and
-reset the cache.
-
-### Configuration
-
-#### `registry`
-
-* Default: "https://registry.npmjs.org/"
-* Type: URL
-
-The base URL of the npm registry.
-
-
-
-### See Also
-
-* [npm bugs](/commands/npm-bugs)
-* [npm help](/commands/npm-help)
-* [npm ping](/commands/npm-ping)