jfrog-cli-v2-jf 2.6.0

package/node-v8.11.1-linux-x64/lib/node_modules/npm/doc/cli/npm-version.md

@@ -0,0 +1,119 @@
+npm-version(1) -- Bump a package version
+========================================
+
+## SYNOPSIS
+
+    npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git]
+
+    'npm [-v | --version]' to print npm version
+    'npm view <pkg> version' to view a package's published version
+    'npm ls' to inspect current package/dependency versions
+
+## DESCRIPTION
+
+Run this in a package directory to bump the version and write the new
+data back to `package.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 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:
+
+    npm version patch -m "Upgrade to %s for reasons"
+
+If the `sign-git-tag` config 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:
+
+    $ 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:
+
+    "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.
+
+## 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.
+
+### git-tag-version
+
+* Default: true
+* Type: Boolean
+
+Commit and tag the version change.
+
+### commit-hooks
+
+* Default: true
+* Type: Boolean
+
+Run git commit hooks when committing the version change.
+
+### sign-git-tag
+
+* Default: false
+* Type: Boolean
+
+Pass the `-s` flag to git to sign the tag.
+
+Note that you must have a default GPG key set up in your git config for this to work properly.
+
+## SEE ALSO
+
+* npm-init(1)
+* npm-run-script(1)
+* npm-scripts(7)
+* package.json(5)
+* semver(7)
+* config(7)

package/node-v8.11.1-linux-x64/lib/node_modules/npm/doc/cli/npm-view.md

@@ -0,0 +1,96 @@
+npm-view(1) -- View registry info
+=================================
+
+## SYNOPSIS
+
+    npm view [<@scope>/]<name>[@<version>] [<field>[.<subfield>]...]
+
+    aliases: info, show, v
+
+## DESCRIPTION
+
+This command shows data about a package and prints it to the stream
+referenced by the `outfd` config, which defaults to stdout.
+
+To show the package registry entry for the `connect` package, you can do
+this:
+
+    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:
+
+    npm view ronn@0.3.5 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 could
+do this:
+
+    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 can do this:
+
+    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 names for the "express" project, you can do this:
+
+    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 do this:
+
+    npm view express contributors[0].email
+
+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:
+
+    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(5)` for more on this.)
+
+    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:
+
+    npm view yui3@'>0.5.4' dependencies.jsdom
+
+To show the `connect` package version history, you can do
+this:
+
+    npm view connect versions
+
+## OUTPUT
+
+If only a single string field for a single version is output, then it
+will not be colorized or quoted, so as 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, than each printed value
+will be prefixed with the version it applies to.
+
+If multiple fields are requested, than each of them are prefixed with
+the field name.
+
+## SEE ALSO
+
+* npm-search(1)
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-docs(1)

package/node-v8.11.1-linux-x64/lib/node_modules/npm/doc/cli/npm-whoami.md

@@ -0,0 +1,17 @@
+npm-whoami(1) -- Display npm username
+=====================================
+
+## SYNOPSIS
+
+    npm whoami [--registry <registry>]
+
+## DESCRIPTION
+
+Print the `username` config to standard output.
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-adduser(1)

package/node-v8.11.1-linux-x64/lib/node_modules/npm/doc/cli/npm.md

@@ -0,0 +1,165 @@
+npm(1) -- javascript package manager
+====================================
+
+## SYNOPSIS
+
+    npm <command> [args]
+
+## VERSION
+
+@VERSION@
+
+## 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 wide variety of use cases.
+Most commonly, it is used to publish, discover, install, and develop node
+programs.
+
+Run `npm help` to get a list of available commands.
+
+## INTRODUCTION
+
+You probably got npm because you want to install stuff.
+
+Use `npm install blerg` to install the latest version of "blerg".  Check out
+`npm-install(1)` for more info.  It can do a lot of stuff.
+
+Use the `npm search` command to show everything that's available.
+Use `npm ls` to show everything you've installed.
+
+## DEPENDENCIES
+
+If a package references to another package with a git URL, npm depends
+on a preinstalled git.
+
+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/TooTallNate/node-gyp) for that task.
+For a Unix system, [node-gyp](https://github.com/TooTallNate/node-gyp)
+needs Python, make and a buildchain like GCC. On Windows,
+Python and Microsoft Visual Studio C++ are needed. Python 3 is
+not supported by [node-gyp](https://github.com/TooTallNate/node-gyp).
+For more information visit
+[the node-gyp repository](https://github.com/TooTallNate/node-gyp) and
+the [node-gyp Wiki](https://github.com/TooTallNate/node-gyp/wiki).
+
+## DIRECTORIES
+
+See `npm-folders(5)` to learn about where npm puts stuff.
+
+In particular, npm has two modes of operation:
+
+* global mode:  
+  npm installs packages into the install prefix at
+  `prefix/lib/node_modules` and bins are installed in `prefix/bin`.
+* local mode:  
+  npm installs packages into the current project directory, which
+  defaults to the current working directory.  Packages are installed to
+  `./node_modules`, and bins are installed to `./node_modules/.bin`.
+
+Local mode is the default.  Use `-g` or `--global` on any command to
+operate 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(5)`.
+* link:
+  For linking 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` 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`
+* adduser:
+  Create an account or log in.  Credentials are stored in the
+  user config file.
+* publish:
+  Use the `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 no value is provided, 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, then that will be used instead.
+* Global Configs:  
+  The file found at ../etc/npmrc (from the node executable, by default
+  this resolves to /usr/local/etc/npmrc) will be parsed if it is found.
+  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-defs.js.  These must not be changed.
+
+See `npm-config(7)` for much much more information.
+
+## CONTRIBUTIONS
+
+Patches welcome!
+
+* code:
+  Read through `npm-coding-style(7)` if you plan to submit code.
+  You don't have to agree with it, but you do have to follow it.
+* docs:
+  If you find an error in the documentation, edit the appropriate markdown
+  file in the "doc" folder.  (Don't worry about generating the man page.)
+
+Contributors are listed in npm's `package.json` file.  You can view them
+easily by doing `npm view npm contributors`.
+
+If you would like to contribute, but don't know what to work on, read
+the contributing guidelines and check the issues list.
+
+* https://github.com/npm/npm/wiki/Contributing-Guidelines
+* <https://github.com/npm/npm/issues>
+
+## BUGS
+
+When you find issues, please report them:
+
+* web:
+  <https://github.com/npm/npm/issues>
+
+Be sure to include *all* of the output from the npm command that didn't work
+as expected.  The `npm-debug.log` file is also helpful to provide.
+
+You can also look for isaacs in #node.js on irc://irc.freenode.net.  He
+will no doubt tell you to put the output in a gist or email.
+
+## AUTHOR
+
+[Isaac Z. Schlueter](http://blog.izs.me/) ::
+[isaacs](https://github.com/isaacs/) ::
+[@izs](http://twitter.com/izs) ::
+<i@izs.me>
+
+## SEE ALSO
+
+* npm-help(1)
+* README
+* package.json(5)
+* npm-install(1)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-index(7)

package/node-v8.11.1-linux-x64/lib/node_modules/npm/doc/files/npm-folders.md

@@ -0,0 +1,213 @@
+npm-folders(5) -- 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 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(7)` 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.
+
+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(1)`.  Cache files are stored in `~/.npm` on Posix, or
+`~/npm-cache` on Windows.
+
+This is controlled by the `cache` configuration param.
+
+### Temp Files
+
+Temporary files are stored by default in the folder specified by the
+`tmp` config, 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` configuration 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 it 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.
+
+#### Example
+
+Consider this dependency graph:
+
+    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:
+
+    foo
+    +-- node_modules
+        +-- blerg (1.2.5) <---[A]
+        +-- bar (1.2.3) <---[B]
+        |   `-- node_modules
+        |       +-- baz (2.0.2) <---[C]
+        |       |   `-- node_modules
+        |       |       `-- quux (3.2.0)
+        |       `-- asdf (2.3.4)
+        `-- baz (1.2.3) <---[D]
+            `-- node_modules
+                `-- 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, so those are installed in
+bar's `node_modules` folder.  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].
+
+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.
+
+Underneath `foo -> baz` [D], 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 `bundledDependencies` 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(5)` for more information.
+
+## SEE ALSO
+
+* package.json(5)
+* npm-install(1)
+* npm-pack(1)
+* npm-cache(1)
+* npm-config(1)
+* npmrc(5)
+* npm-config(7)
+* npm-publish(1)