jfrog-cli-v2-jf 2.6.0

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

@@ -0,0 +1,90 @@
+npm-orgs(7) -- Working with Teams & Orgs
+========================================
+
+## DESCRIPTION
+
+There are three levels of org users:
+
+1. Super admin, controls billing & adding people to the org.
+2. Team admin, manages team membership & package access.
+3. Developer, works on packages they are given access to.  
+
+The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a `developers` team that all users are automatically added to.
+
+The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals.
+
+The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.
+
+There are two main commands:
+
+1. `npm team` see npm-team(1) for more details
+2. `npm access` see npm-access(1) for more details
+
+## Team Admins create teams
+
+* Check who you’ve added to your org:
+
+```
+npm team ls <org>:developers
+```
+
+* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the `access` command.
+
+* Create a new team:
+
+```
+npm team create <org:team>
+```
+
+* Add members to that team:
+
+```
+npm team add <org:team> <user>
+```
+
+## Publish a package and adjust package access
+
+* In package directory, run
+
+```
+npm init --scope=<org>
+```
+to scope it for your org & publish as usual
+
+* Grant access:  
+
+```
+npm access grant <read-only|read-write> <org:team> [<package>]
+```
+
+* Revoke access:
+
+```
+npm access revoke <org:team> [<package>]
+```
+
+## Monitor your package access
+
+* See what org packages a team member can access:
+
+```
+npm access ls-packages <org> <user>
+```
+
+* See packages available to a specific team:
+
+```
+npm access ls-packages <org:team>
+```
+
+* Check which teams are collaborating on a package:
+
+```
+npm access ls-collaborators <pkg>
+```
+
+## SEE ALSO
+
+* npm-team(1)
+* npm-access(1)
+* npm-scope(7)

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

@@ -0,0 +1,92 @@
+npm-registry(7) -- The JavaScript Package Registry
+==================================================
+
+## DESCRIPTION
+
+To resolve packages by name and version, npm talks to a registry website
+that implements the CommonJS Package Registry specification for reading
+package info.
+
+Additionally, npm's package registry implementation supports several
+write APIs as well, to allow for publishing packages and managing user
+account information.
+
+The official public npm registry is at <https://registry.npmjs.org/>.  It
+is powered by a CouchDB database, of which there is a public mirror at
+<https://skimdb.npmjs.com/registry>.  The code for the couchapp is
+available at <https://github.com/npm/npm-registry-couchapp>.
+
+The registry URL used is determined by the scope of the package (see
+`npm-scope(7)`). If no scope is specified, the default registry is used, which is
+supplied by the `registry` config parameter.  See `npm-config(1)`,
+`npmrc(5)`, and `npm-config(7)` for more on managing npm's configuration.
+
+## Does npm send any information about me back to the registry?
+
+Yes.
+
+When making requests of the registry npm adds two headers with information
+about your environment:
+
+* `Npm-Scope` – If your project is scoped, this header will contain its
+  scope. In the future npm hopes to build registry features that use this
+  information to allow you to customize your experience for your
+  organization.
+* `Npm-In-CI` – Set to "true" if npm believes this install is running in a
+  continous integration environment, "false" otherwise. This is detected by
+  looking for the following environment variables: `CI`, `TDDIUM`,
+  `JENKINS_URL`, `bamboo.buildKey`. If you'd like to learn more you may find
+  the [original PR](https://github.com/npm/npm-registry-client/pull/129)
+  interesting.
+  This is used to gather better metrics on how npm is used by humans, versus
+  build farms.
+
+The npm registry does not to correlate the information in these headers with
+any authenticated accounts that may be used in the same requests.
+
+## Can I run my own private registry?
+
+Yes!
+
+The easiest way is to replicate the couch database, and use the same (or
+similar) design doc to implement the APIs.
+
+If you set up continuous replication from the official CouchDB, and then
+set your internal CouchDB as the registry config, then you'll be able
+to read any published packages, in addition to your private ones, and by
+default will only publish internally. 
+
+If you then want to publish a package for the whole world to see, you can
+simply override the `--registry` option for that `publish` command.
+
+## I don't want my package published in the official registry. It's private.
+
+Set `"private": true` in your package.json to prevent it from being
+published at all, or
+`"publishConfig":{"registry":"http://my-internal-registry.local"}`
+to force it to be published only to your internal registry.
+
+See `package.json(5)` for more info on what goes in the package.json file.
+
+## Will you replicate from my registry into the public one?
+
+No.  If you want things to be public, then publish them into the public
+registry using npm.  What little security there is would be for nought
+otherwise.
+
+## Do I have to use couchdb to build a registry that npm can talk to?
+
+No, but it's way easier.  Basically, yes, you do, or you have to
+effectively implement the entire CouchDB API anyway.
+
+## Is there a website or something to see package docs and such?
+
+Yes, head over to <https://npmjs.com/>
+
+## SEE ALSO
+
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-developers(7)
+* npm-disputes(7)

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

@@ -0,0 +1,113 @@
+npm-scope(7) -- Scoped packages
+===============================
+
+## DESCRIPTION
+
+All npm packages have a name. Some package names also have a scope. A scope
+follows the usual rules for package names (URL-safe characters, no leading dots
+or underscores). When used in package names, scopes are preceded by an `@` symbol
+and followed by a slash, e.g.
+
+    @somescope/somepackagename
+
+Scopes are a way of grouping related packages together, and also affect a few
+things about the way npm treats the package.
+
+Each npm user/organization has their own scope, and only you can add packages
+in your scope. This means you don't have to worry about someone taking your
+package name ahead of you. Thus it is also a good way to signal official packages
+for organizations.
+
+Scoped packages can be published and installed as of `npm@2` and are supported
+by the primary npm registry. Unscoped packages can depend on scoped packages and
+vice versa. The npm client is backwards-compatible with unscoped registries,
+so it can be used to work with scoped and unscoped registries at the same time.
+
+## Installing scoped packages
+
+Scoped packages are installed to a sub-folder of the regular installation
+folder, e.g. if your other packages are installed in `node_modules/packagename`,
+scoped modules will be installed in `node_modules/@myorg/packagename`. The scope
+folder (`@myorg`) is simply the name of the scope preceded by an `@` symbol, and can
+contain any number of scoped packages.
+
+A scoped package is installed by referencing it by name, preceded by an
+`@` symbol, in `npm install`:
+
+    npm install @myorg/mypackage
+
+Or in `package.json`:
+
+    "dependencies": {
+      "@myorg/mypackage": "^1.3.0"
+    }
+
+Note that if the `@` symbol is omitted, in either case, npm will instead attempt to
+install from GitHub; see `npm-install(1)`.
+
+## Requiring scoped packages
+
+Because scoped packages are installed into a scope folder, you have to
+include the name of the scope when requiring them in your code, e.g.
+
+    require('@myorg/mypackage')
+
+There is nothing special about the way Node treats scope folders. This
+simply requires the `mypackage` module in the folder named `@myorg`.
+
+## Publishing scoped packages
+
+Scoped packages can be published from the CLI as of `npm@2` and can be
+published to any registry that supports them, including the primary npm
+registry.
+
+(As of 2015-04-19, and with npm 2.0 or better, the primary npm registry
+**does** support scoped packages.)
+
+If you wish, you may associate a scope with a registry; see below.
+
+### Publishing public scoped packages to the primary npm registry
+
+To publish a public scoped package, you must specify `--access public` with
+the initial publication. This will publish the package and set access
+to `public` as if you had run `npm access public` after publishing.
+
+### Publishing private scoped packages to the npm registry
+
+To publish a private scoped package to the npm registry, you must have
+an [npm Private Modules](https://www.npmjs.com/private-modules)
+account.
+
+You can then publish the module with `npm publish` or `npm publish
+--access restricted`, and it will be present in the npm registry, with
+restricted access. You can then change the access permissions, if
+desired, with `npm access` or on the npmjs.com website.
+
+## Associating a scope with a registry
+
+Scopes can be associated with a separate registry. This allows you to
+seamlessly use a mix of packages from the primary npm registry and one or more
+private registries, such as npm Enterprise.
+
+You can associate a scope with a registry at login, e.g.
+
+    npm login --registry=http://reg.example.com --scope=@myco
+
+Scopes have a many-to-one relationship with registries: one registry can
+host multiple scopes, but a scope only ever points to one registry.
+
+You can also associate a scope with a registry using `npm config`:
+
+    npm config set @myco:registry http://reg.example.com
+
+Once a scope is associated with a registry, any `npm install` for a package
+with that scope will request packages from that registry instead. Any
+`npm publish` for a package name that contains the scope will be published to
+that registry instead.
+
+## SEE ALSO
+
+* npm-install(1)
+* npm-publish(1)
+* npm-access(1)
+* npm-registry(7)

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

@@ -0,0 +1,266 @@
+npm-scripts(7) -- How npm handles the "scripts" field
+=====================================================
+
+## DESCRIPTION
+
+npm supports the "scripts" property of the package.json file, for the
+following scripts:
+
+* prepublish:
+  Run BEFORE the package is packed and published, as well as on local `npm
+  install` without any arguments. (See below)
+* prepare:
+  Run both BEFORE the package is packed and published, and on local `npm
+  install` without any arguments (See below). This is run
+  AFTER `prepublish`, but BEFORE `prepublishOnly`.
+* prepublishOnly:
+  Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
+  below.)
+* prepack:
+  run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
+  installing git dependencies)
+* postpack:
+  Run AFTER the tarball has been generated and moved to its final destination.
+* publish, postpublish:
+  Run AFTER the package is published.
+* preinstall:
+  Run BEFORE the package is installed
+* install, postinstall:
+  Run AFTER the package is installed.
+* preuninstall, uninstall:
+  Run BEFORE the package is uninstalled.
+* postuninstall:
+  Run AFTER the package is uninstalled.
+* preversion:
+  Run BEFORE bumping the package version.
+* version:
+  Run AFTER bumping the package version, but BEFORE commit.
+* postversion:
+  Run AFTER bumping the package version, and AFTER commit.
+* pretest, test, posttest:
+  Run by the `npm test` command.
+* prestop, stop, poststop:
+  Run by the `npm stop` command.
+* prestart, start, poststart:
+  Run by the `npm start` command.
+* prerestart, restart, postrestart:
+  Run by the `npm restart` command. Note: `npm restart` will run the
+  stop and start scripts if no `restart` script is provided.
+* preshrinkwrap, shrinkwrap, postshrinkwrap:
+  Run by the `npm shrinkwrap` command.
+
+Additionally, arbitrary scripts can be executed by running `npm
+run-script <stage>`. *Pre* and *post* commands with matching
+names will be run for those as well (e.g. `premyscript`, `myscript`,
+`postmyscript`). Scripts from dependencies can be run with `npm explore
+<pkg> -- npm run <stage>`.
+
+## PREPUBLISH AND PREPARE
+
+### DEPRECATION NOTE
+
+Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
+publish` and `npm install`, because it's a convenient way to prepare a package
+for use (some common use cases are described in the section below).  It has
+also turned out to be, in practice, [very
+confusing](https://github.com/npm/npm/issues/10074).  As of `npm@4.0.0`, a new
+event has been introduced, `prepare`, that preserves this existing behavior. A
+_new_ event, `prepublishOnly` has been added as a transitional strategy to
+allow users to avoid the confusing behavior of existing npm versions and only
+run on `npm publish` (for instance, running the tests one last time to ensure
+they're in good shape).
+
+See <https://github.com/npm/npm/issues/10074> for a much lengthier
+justification, with further reading, for this change.
+
+### USE CASES
+
+If you need to perform operations on your package before it is used, in a way
+that is not dependent on the operating system or architecture of the
+target system, use a `prepublish` script.  This includes
+tasks such as:
+
+* Compiling CoffeeScript source code into JavaScript.
+* Creating minified versions of JavaScript source code.
+* Fetching remote resources that your package will use.
+
+The advantage of doing these things at `prepublish` time is that they can be done once, in a
+single place, thus reducing complexity and variability.
+Additionally, this means that:
+
+* You can depend on `coffee-script` as a `devDependency`, and thus
+  your users don't need to have it installed.
+* You don't need to include minifiers in your package, reducing
+  the size for your users.
+* You don't need to rely on your users having `curl` or `wget` or
+  other system tools on the target machines.
+
+## DEFAULT VALUES
+
+npm will default some script values based on package contents.
+
+* `"start": "node server.js"`:
+
+  If there is a `server.js` file in the root of your package, then npm
+  will default the `start` command to `node server.js`.
+
+* `"install": "node-gyp rebuild"`:
+
+  If there is a `binding.gyp` file in the root of your package and you
+  haven't defined your own `install` or `preinstall` scripts, npm will
+  default the `install` command to compile using node-gyp.
+
+## USER
+
+If npm was invoked with root privileges, then it will change the uid
+to the user account or uid specified by the `user` config, which
+defaults to `nobody`.  Set the `unsafe-perm` flag to run scripts with
+root privileges.
+
+## ENVIRONMENT
+
+Package scripts run in an environment where many pieces of information
+are made available regarding the setup of npm and the current state of
+the process.
+
+
+### path
+
+If you depend on modules that define executable scripts, like test
+suites, then those executables will be added to the `PATH` for
+executing the scripts.  So, if your package.json has this:
+
+    { "name" : "foo"
+    , "dependencies" : { "bar" : "0.1.x" }
+    , "scripts": { "start" : "bar ./test" } }
+
+then you could run `npm start` to execute the `bar` script, which is
+exported into the `node_modules/.bin` directory on `npm install`.
+
+### package.json vars
+
+The package.json fields are tacked onto the `npm_package_` prefix. So,
+for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your
+package.json file, then your package scripts would have the
+`npm_package_name` environment variable set to "foo", and the
+`npm_package_version` set to "1.2.5"
+
+### configuration
+
+Configuration parameters are put in the environment with the
+`npm_config_` prefix. For instance, you can view the effective `root`
+config by checking the `npm_config_root` environment variable.
+
+### Special: package.json "config" object
+
+The package.json "config" keys are overwritten in the environment if
+there is a config param of `<name>[@<version>]:<key>`.  For example,
+if the package.json has this:
+
+    { "name" : "foo"
+    , "config" : { "port" : "8080" }
+    , "scripts" : { "start" : "node server.js" } }
+
+and the server.js is this:
+
+    http.createServer(...).listen(process.env.npm_package_config_port)
+
+then the user could change the behavior by doing:
+
+    npm config set foo:port 80
+
+### current lifecycle event
+
+Lastly, the `npm_lifecycle_event` environment variable is set to
+whichever stage of the cycle is being executed. So, you could have a
+single script used for different parts of the process which switches
+based on what's currently happening.
+
+Objects are flattened following this format, so if you had
+`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd
+see this in the script:
+
+    process.env.npm_package_scripts_install === "foo.js"
+
+## EXAMPLES
+
+For example, if your package.json contains this:
+
+    { "scripts" :
+      { "install" : "scripts/install.js"
+      , "postinstall" : "scripts/install.js"
+      , "uninstall" : "scripts/uninstall.js"
+      }
+    }
+
+then `scripts/install.js` will be called for the install
+and post-install stages of the lifecycle, and `scripts/uninstall.js`
+will be called when the package is uninstalled.  Since
+`scripts/install.js` is running for two different phases, it would
+be wise in this case to look at the `npm_lifecycle_event` environment
+variable.
+
+If you want to run a make command, you can do so.  This works just
+fine:
+
+    { "scripts" :
+      { "preinstall" : "./configure"
+      , "install" : "make && make install"
+      , "test" : "make test"
+      }
+    }
+
+## EXITING
+
+Scripts are run by passing the line as a script argument to `sh`.
+
+If the script exits with a code other than 0, then this will abort the
+process.
+
+Note that these script files don't have to be nodejs or even
+javascript programs. They just have to be some kind of executable
+file.
+
+## HOOK SCRIPTS
+
+If you want to run a specific script at a specific lifecycle event for
+ALL packages, then you can use a hook script.
+
+Place an executable file at `node_modules/.hooks/{eventname}`, and
+it'll get run for all packages when they are going through that point
+in the package lifecycle for any packages installed in that root.
+
+Hook scripts are run exactly the same way as package.json scripts.
+That is, they are in a separate child process, with the env described
+above.
+
+## BEST PRACTICES
+
+* Don't exit with a non-zero error code unless you *really* mean it.
+  Except for uninstall scripts, this will cause the npm action to
+  fail, and potentially be rolled back.  If the failure is minor or
+  only will prevent some optional features, then it's better to just
+  print a warning and exit successfully.
+* Try not to use scripts to do what npm can do for you.  Read through
+  `package.json(5)` to see all the things that you can specify and enable
+  by simply describing your package appropriately.  In general, this
+  will lead to a more robust and consistent state.
+* Inspect the env to determine where to put things.  For instance, if
+  the `npm_config_binroot` environment variable is set to `/home/user/bin`, then
+  don't try to install executables into `/usr/local/bin`.  The user
+  probably set it up that way for a reason.
+* Don't prefix your script commands with "sudo".  If root permissions
+  are required for some reason, then it'll fail with that error, and
+  the user will sudo the npm command in question.
+* Don't use `install`. Use a `.gyp` file for compilation, and `prepublish`
+  for anything else. You should almost never have to explicitly set a
+  preinstall or install script. If you are doing this, please consider if
+  there is another option. The only valid use of `install` or `preinstall`
+  scripts is for compilation which must be done on the target architecture.
+
+## SEE ALSO
+
+* npm-run-script(1)
+* package.json(5)
+* npm-developers(7)
+* npm-install(1)

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

@@ -0,0 +1,54 @@
+npm-removal(1) -- Cleaning the Slate
+====================================
+
+## SYNOPSIS
+
+So sad to see you go.
+
+    sudo npm uninstall npm -g
+
+Or, if that fails, get the npm source code, and do:
+
+    sudo make uninstall
+
+## More Severe Uninstalling
+
+Usually, the above instructions are sufficient.  That will remove
+npm, but leave behind anything you've installed.
+
+If that doesn't work, or if you require more drastic measures,
+continue reading.
+
+Note that this is only necessary for globally-installed packages.  Local
+installs are completely contained within a project's `node_modules`
+folder.  Delete that folder, and everything is gone (unless a package's
+install script is particularly ill-behaved).
+
+This assumes that you installed node and npm in the default place.  If
+you configured node with a different `--prefix`, or installed npm with a
+different prefix setting, then adjust the paths accordingly, replacing
+`/usr/local` with your install prefix.
+
+To remove everything npm-related manually:
+
+    rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
+
+If you installed things *with* npm, then your best bet is to uninstall
+them with npm first, and then install them again once you have a
+proper install.  This can help find any symlinks that are lying
+around:
+
+    ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
+
+Prior to version 0.3, npm used shim files for executables and node
+modules.  To track those down, you can do the following:
+
+    find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
+
+(This is also in the README file.)
+
+## SEE ALSO
+
+* README
+* npm-uninstall(1)
+* npm-prune(1)