@patternfly-java/charts 0.0.1 → 0.0.3

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

@@ -1,235 +0,0 @@
----
-title: npm-version
-section: 1
-description: Bump a package version
----
-
-### Synopsis
-
-```bash
-npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git]
-
-alias: verison
-```
-
-### Configuration
-
-#### `allow-same-version`
-
-* Default: false
-* Type: Boolean
-
-Prevents throwing an error when `npm version` is used to set the new version
-to the same value as the current version.
-
-
-
-#### `commit-hooks`
-
-* Default: true
-* Type: Boolean
-
-Run git commit hooks when using the `npm version` command.
-
-
-
-#### `git-tag-version`
-
-* Default: true
-* Type: Boolean
-
-Tag the commit when using the `npm version` command. Setting this to false
-results in no commit being made at all.
-
-
-
-#### `json`
-
-* Default: false
-* Type: Boolean
-
-Whether or not to output JSON data, rather than the normal output.
-
-* In `npm pkg set` it enables parsing set values with JSON.parse() before
-  saving them to your `package.json`.
-
-Not supported by all npm commands.
-
-
-
-#### `preid`
-
-* Default: ""
-* Type: String
-
-The "prerelease identifier" to use as a prefix for the "prerelease" part of
-a semver. Like the `rc` in `1.2.0-rc.8`.
-
-
-
-#### `sign-git-tag`
-
-* Default: false
-* Type: Boolean
-
-If set to true, then the `npm version` command will tag the version using
-`-s` to add a signature.
-
-Note that git requires you to have set up GPG keys in your git configs for
-this to work properly.
-
-
-
-#### `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.
-
-#### `workspaces-update`
-
-* Default: true
-* Type: Boolean
-
-If set to true, the npm cli will run an update after operations that may
-possibly change the workspaces installed to the `node_modules` folder.
-
-
-
-#### `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.
-
-### Description
-
-Run this in a package directory to bump the version and write the new data
-back to `package.json`, `package-lock.json`, and, if present,
-`npm-shrinkwrap.json`.
-
-The `newversion` argument should be a valid semver string, a valid second
-argument to [semver.inc](https://github.com/npm/node-semver#functions) (one
-of `patch`, `minor`, `major`, `prepatch`, `preminor`, `premajor`,
-`prerelease`), or `from-git`. In the second case, the existing version will
-be incremented by 1 in the specified field.  `from-git` will try to read
-the latest git tag, and use that as the new npm version.
-
-If run in a git repo, it will also create a version commit and tag.  This
-behavior is controlled by `git-tag-version` (see below), and can be
-disabled on the command line by running `npm --no-git-tag-version version`.
-It will fail if the working directory is not clean, unless the `-f` or
-`--force` flag is set.
-
-If supplied with `-m` or [`--message` config](/using-npm/config#message) option,
-npm will use it as a commit message when creating a version commit.  If the
-`message` config contains `%s` then that will be replaced with the resulting
-version number. For example:
-
-```bash
-npm version patch -m "Upgrade to %s for reasons"
-```
-
-If the [`sign-git-tag` config](/using-npm/config#sign-git-tag) is set, then the
-tag will be signed using the `-s` flag to git. Note that you must have a default
-GPG key set up in your git config for this to work properly. For example:
-
-```bash
-$ npm config set sign-git-tag true
-$ npm version patch
-
-You need a passphrase to unlock the secret key for
-user: "isaacs (http://blog.izs.me/) <i@izs.me>"
-2048-bit RSA key, ID 6C481CF6, created 2010-08-31
-
-Enter passphrase:
-```
-
-If `preversion`, `version`, or `postversion` are in the `scripts` property
-of the package.json, they will be executed as part of running `npm
-version`.
-
-The exact order of execution is as follows:
-
-1. Check to make sure the git working directory is clean before we get
-   started.  Your scripts may add files to the commit in future steps.
-   This step is skipped if the `--force` flag is set.
-2. Run the `preversion` script. These scripts have access to the old
-   `version` in package.json.  A typical use would be running your full
-   test suite before deploying.  Any files you want added to the commit
-   should be explicitly added using `git add`.
-3. Bump `version` in `package.json` as requested (`patch`, `minor`,
-   `major`, etc).
-4. Run the `version` script. These scripts have access to the new `version`
-   in package.json (so they can incorporate it into file headers in
-   generated files for example).  Again, scripts should explicitly add
-   generated files to the commit using `git add`.
-5. Commit and tag.
-6. Run the `postversion` script. Use it to clean up the file system or
-   automatically push the commit and/or tag.
-
-Take the following example:
-
-```json
-{
-  "scripts": {
-    "preversion": "npm test",
-    "version": "npm run build && git add -A dist",
-    "postversion": "git push && git push --tags && rm -rf build/temp"
-  }
-}
-```
-
-This runs all your tests and proceeds only if they pass. Then runs your
-`build` script, and adds everything in the `dist` directory to the commit.
-After the commit, it pushes the new commit and tag up to the server, and
-deletes the `build/temp` directory.
-
-### See Also
-
-* [npm init](/commands/npm-init)
-* [npm run](/commands/npm-run)
-* [npm scripts](/using-npm/scripts)
-* [package.json](/configuring-npm/package-json)
-* [config](/using-npm/config)

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

@@ -1,200 +0,0 @@
----
-title: npm-view
-section: 1
-description: View registry info
----
-
-### Synopsis
-
-```bash
-npm view [<package-spec>] [<field>[.subfield]...]
-
-aliases: info, show, v
-```
-
-### Description
-
-This command shows data about a package and prints it to stdout.
-
-As an example, to view information about the `connect` package from the registry, you would run:
-
-```bash
-npm view connect
-```
-
-The default version is `"latest"` if unspecified.
-
-Field names can be specified after the package descriptor.
-For example, to show the dependencies of the `ronn` package at version
-`0.3.5`, you could do the following:
-
-```bash
-npm view ronn@0.3.5 dependencies
-```
-
-By default, `npm view` shows data about the current project context (by looking for a `package.json`).
-To show field data for the current project use a file path (i.e. `.`):
-
-```bash
-npm view . dependencies
-```
-
-You can view child fields by separating them with a period.
-To view the git repository URL for the latest version of `npm`, you would run the following command:
-
-```bash
-npm view npm repository.url
-```
-
-This makes it easy to view information about a dependency with a bit of
-shell scripting. For example, to view all the data about the version of
-`opts` that `ronn` depends on, you could write the following:
-
-```bash
-npm view opts@$(npm view ronn dependencies.opts)
-```
-
-For fields that are arrays, requesting a non-numeric field will return
-all of the values from the objects in the list. For example, to get all
-the contributor email addresses for the `express` package, you would run:
-
-```bash
-npm view express contributors.email
-```
-
-You may also use numeric indices in square braces to specifically select
-an item in an array field. To just get the email address of the first
-contributor in the list, you can run:
-
-```bash
-npm view express contributors[0].email
-```
-
-If the field value you are querying for is a property of an object, you should run:
-
-```bash
-npm view express time'[4.8.0]'
-```
-
-Multiple fields may be specified, and will be printed one after another.
-For example, to get all the contributor names and email addresses, you
-can do this:
-
-```bash
-npm view express contributors.name contributors.email
-```
-
-"Person" fields are shown as a string if they would be shown as an
-object.  So, for example, this will show the list of `npm` contributors in
-the shortened string format.  (See [`package.json`](/configuring-npm/package-json) for more on this.)
-
-```bash
-npm view npm contributors
-```
-
-If a version range is provided, then data will be printed for every
-matching version of the package.  This will show which version of `jsdom`
-was required by each matching version of `yui3`:
-
-```bash
-npm view yui3@'>0.5.4' dependencies.jsdom
-```
-
-To show the `connect` package version history, you can do
-this:
-
-```bash
-npm view connect versions
-```
-
-### Configuration
-
-#### `json`
-
-* Default: false
-* Type: Boolean
-
-Whether or not to output JSON data, rather than the normal output.
-
-* In `npm pkg set` it enables parsing set values with JSON.parse() before
-  saving them to your `package.json`.
-
-Not supported by all npm commands.
-
-
-
-#### `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.
-
-### Output
-
-If only a single string field for a single version is output, then it
-will not be colorized or quoted, to enable piping the output to
-another command. If the field is an object, it will be output as a JavaScript object literal.
-
-If the `--json` flag is given, the outputted fields will be JSON.
-
-If the version range matches multiple versions then each printed value
-will be prefixed with the version it applies to.
-
-If multiple fields are requested, then each of them is prefixed with
-the field name.
-
-### See Also
-
-* [package spec](/using-npm/package-spec)
-* [npm search](/commands/npm-search)
-* [npm registry](/using-npm/registry)
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)
-* [npm docs](/commands/npm-docs)

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

@@ -1,41 +0,0 @@
----
-title: npm-whoami
-section: 1
-description: Display npm username
----
-
-### Synopsis
-
-```bash
-npm whoami
-```
-
-Note: This command is unaware of workspaces.
-
-### Description
-
-Display the npm username of the currently logged-in user.
-
-If logged into a registry that provides token-based authentication, then
-connect to the `/-/whoami` registry endpoint to find the username
-associated with the token, and print to standard output.
-
-If logged into a registry that uses Basic Auth, then simply print the
-`username` portion of the authentication string.
-
-### Configuration
-
-#### `registry`
-
-* Default: "https://registry.npmjs.org/"
-* Type: URL
-
-The base URL of the npm registry.
-
-
-
-### See Also
-
-* [npm config](/commands/npm-config)
-* [npmrc](/configuring-npm/npmrc)
-* [npm adduser](/commands/npm-adduser)

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

@@ -1,175 +0,0 @@
----
-title: npm
-section: 1
-description: javascript package manager
----
-
-### Synopsis
-
-```bash
-npm
-```
-
-Note: This command is unaware of workspaces.
-
-### Version
-
-11.6.1
-
-### Description
-
-npm is the package manager for the Node JavaScript platform.  It puts
-modules in place so that node can find them, and manages dependency
-conflicts intelligently.
-
-It is extremely configurable to support a variety of use cases.  Most
-commonly, you use it to publish, discover, install, and develop node
-programs.
-
-Run `npm help` to get a list of available commands.
-
-### Important
-
-npm comes preconfigured to use npm's public registry at
-https://registry.npmjs.org by default. Use of the npm public registry is
-subject to terms of use available at
-https://docs.npmjs.com/policies/terms.
-
-You can configure npm to use any compatible registry you like, and even
-run your own registry. Use of someone else's registry is governed by
-their terms of use.
-
-### Introduction
-
-You probably got npm because you want to install stuff.
-
-The very first thing you will most likely want to run in any node
-program is `npm install` to install its dependencies.
-
-You can also run `npm install blerg` to install the latest version of
-"blerg".  Check out [`npm install`](/commands/npm-install) for more
-info.  It can do a lot of stuff.
-
-Use the `npm search` command to show everything that's available in the
-public registry.  Use `npm ls` to show everything you've installed.
-
-### Dependencies
-
-If a package lists a dependency using a git URL, npm will install that
-dependency using the [`git`](https://github.com/git-guides/install-git)
-command and will generate an error if it is not installed.
-
-If one of the packages npm tries to install is a native node module and
-requires compiling of C++ Code, npm will use
-[node-gyp](https://github.com/nodejs/node-gyp) for that task.
-For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp)
-needs Python, make and a buildchain like GCC. On Windows,
-Python and Microsoft Visual Studio C++ are needed. For more information
-visit [the node-gyp repository](https://github.com/nodejs/node-gyp) and
-the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki).
-
-### Directories
-
-See [`folders`](/configuring-npm/folders) to learn about where npm puts
-stuff.
-
-In particular, npm has two modes of operation:
-
-* local mode:
-  npm installs packages into the current project directory, which
-  defaults to the current working directory.  Packages install to
-  `./node_modules`, and bins to `./node_modules/.bin`.
-* global mode:
-  npm installs packages into the install prefix at
-  `$npm_config_prefix/lib/node_modules` and bins to
-  `$npm_config_prefix/bin`.
-
-Local mode is the default.  Use `-g` or `--global` on any command to
-run in global mode instead.
-
-### Developer Usage
-
-If you're using npm to develop and publish your code, check out the
-following help topics:
-
-* json:
-  Make a package.json file.  See
-  [`package.json`](/configuring-npm/package-json).
-* link:
-  Links your current working code into Node's path, so that you don't
-  have to reinstall every time you make a change.  Use [`npm
-  link`](/commands/npm-link) to do this.
-* install:
-  It's a good idea to install things if you don't need the symbolic
-  link.  Especially, installing other peoples code from the registry is
-  done via [`npm install`](/commands/npm-install)
-* adduser:
-  Create an account or log in.  When you do this, npm will store
-  credentials in the user config file.
-* publish:
-  Use the [`npm publish`](/commands/npm-publish) command to upload your
-  code to the registry.
-
-#### Configuration
-
-npm is extremely configurable.  It reads its configuration options from
-5 places.
-
-* Command line switches:
-  Set a config with `--key val`.  All keys take a value, even if they
-  are booleans (the config parser doesn't know what the options are at
-  the time of parsing).  If you do not provide a value (`--key`) then
-  the option is set to boolean `true`.
-* Environment Variables:
-  Set any config by prefixing the name in an environment variable with
-  `npm_config_`.  For example, `export npm_config_key=val`.
-* User Configs:
-  The file at `$HOME/.npmrc` is an ini-formatted list of configs.  If
-  present, it is parsed.  If the `userconfig` option is set in the cli
-  or env, that file will be used instead.
-* Global Configs:
-  The file found at `./etc/npmrc` (relative to the global prefix will be
-  parsed if it is found.  See [`npm prefix`](/commands/npm-prefix) for
-  more info on the global prefix.  If the `globalconfig` option is set
-  in the cli, env, or user config, then that file is parsed instead.
-* Defaults:
-  npm's default configuration options are defined in
-  `lib/utils/config/definitions.js`.  These must not be changed.
-
-See [`config`](/using-npm/config) for much much more information.
-
-### Contributions
-
-Patches welcome!
-
-If you would like to help, but don't know what to work on, read the
-[contributing
-guidelines](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) and
-check the issues list.
-
-### Bugs
-
-When you find issues, please report them:
-<https://github.com/npm/cli/issues>
-
-Please be sure to follow the template and bug reporting guidelines.
-
-### Feature Requests
-
-Discuss new feature ideas on our discussion forum:
-
-* <https://github.com/orgs/community/discussions/categories/npm>
-
-Or suggest formal RFC proposals:
-
-* <https://github.com/npm/rfcs>
-
-### See Also
-
-* [npm help](/commands/npm-help)
-* [package.json](/configuring-npm/package-json)
-* [npmrc](/configuring-npm/npmrc)
-* [npm config](/commands/npm-config)
-* [npm install](/commands/npm-install)
-* [npm prefix](/commands/npm-prefix)
-* [npm publish](/commands/npm-publish)