mirror of https://github.com/lukechilds/node.git
Forrest L Norvell
9 years ago
committed by
Rod Vagg
Rod Vagg
3364 changed files with 197172 additions and 67128 deletions
@ -0,0 +1,53 @@ |
|||
Alex K. Wolfe <alexkwolfe@gmail.com> |
|||
Andrew Bradley <cspotcode@gmail.com> |
|||
Andrew Lunny <alunny@gmail.com> |
|||
Arlo Breault <arlolra@gmail.com> |
|||
Benjamin Coe <bencoe@gmail.com> |
|||
Benjamin Coe <bencoe@gmail.com> <ben@npmjs.com> |
|||
Brian White <mscdex@mscdex.net> <mscdex@gmail.com> |
|||
Cedric Nelson <cedric.nelson@gmail.com> |
|||
Charlie Robbins <charlie.robbins@gmail.com> |
|||
Dalmais Maxence <root@ip-10-195-202-5.ec2.internal> |
|||
Danila Gerasimov <danila.gerasimov@gmail.com> |
|||
David Beitey <david@davidjb.com> |
|||
Domenic Denicola <domenic@domenicdenicola.com> |
|||
Einar Otto Stangvik <einaros@gmail.com> |
|||
Erik Wienhold <git@ewie.name> |
|||
Evan Lucas <evan@btc.com> <evan.lucas@hattiesburgclinic.com> |
|||
Evan Lucas <evan@btc.com> <evanlucas@me.com> |
|||
Faiq Raza <faiqrazarizvi@gmail.com> |
|||
Forbes Lindesay <forbes@lindesay.co.uk> |
|||
Forrest L Norvell <ogd@aoaioxxysz.net> <forrest@npmjs.com> |
|||
Gabriel Barros <descartavel1@gmail.com> |
|||
Geoff Flarity <geoff.flarity@gmail.com> <gflarity@raptvm-x02.(none)> |
|||
Isaac Z. Schlueter <i@izs.me> <i@foohack.com> |
|||
Isaac Z. Schlueter <i@izs.me> isaacs <i@izs.me> |
|||
Jake Verbaten <raynos2@gmail.com> |
|||
James Sanders <jimmyjazz14@gmail.com> |
|||
Jason Smith <jhs@iriscouch.com> |
|||
Jonas Weber <github@jonasw.de> |
|||
Julien Meddah <julien.meddah@deveryware.com> |
|||
Kris Windham <kriswindham@gmail.com> |
|||
Lin Clark <lin.w.clark@gmail.com> |
|||
Luke Arduini <luke.arduini@gmail.com> <luke.arduini@me.com> |
|||
Maciej Małecki <me@mmalecki.com> <maciej.malecki@notimplemented.org> |
|||
Max Goodman <c@chromakode.com> |
|||
Maxim Bogushevich <boga1@mail.ru> |
|||
Maximilian Antoni <mail@maxantoni.de> <maximilian.antoni@juliusbaer.com> |
|||
Michael Hayes <michael@hayes.io> <mhayes@newrelic.com> |
|||
Nicolas Morel <marsup@gmail.com> |
|||
Olivier Melcher <olivier.melcher@gmail.com> |
|||
Ra'Shaun Stovall <rashaunstovall@gmail.com> |
|||
Rebecca Turner <me@re-becca.org> <turner@mikomi.org> |
|||
Rebecca Turner <me@re-becca.org> <rebecca@npmjs.com> |
|||
Ryan Emery <seebees@gmail.com> |
|||
Sam Mikes <smikes@cubane.com> |
|||
Takaya Kobayashi <jigsaw@live.jp> |
|||
Timo Weiß <timoweiss@Timo-MBP.local> |
|||
Tony <zearin@gonk.net> |
|||
Trent Mick <trentm@gmail.com> <trent.mick@joyent.com> |
|||
Visnu Pitiyanuvath <visnupx@gmail.com> |
|||
Will Elwood <w.elwood08@gmail.com> |
|||
Wout Mertens <Wout.Mertens@gmail.com> |
|||
Yeonghoon Park <sola92@gmail.com> |
|||
Zeke Sikelianos <zeke@sikelianos.com> |
|||
@ -1,2 +0,0 @@ |
|||
save-prefix = ~ |
|||
proprietary-attribs = false |
|||
@ -1,5 +1,18 @@ |
|||
language: node_js |
|||
script: "npm run-script tap" |
|||
sudo: false |
|||
node_js: |
|||
- "0.11" |
|||
- "5" |
|||
- "4" |
|||
- iojs |
|||
- "0.12" |
|||
- "0.10" |
|||
- "0.8" |
|||
env: |
|||
- DEPLOY_VERSION=testing |
|||
before_install: |
|||
- "npm config set spin false" |
|||
- "npm install -g npm/npm#2.x" |
|||
- "mkdir -p /var/run/couchdb" |
|||
script: "npm test" |
|||
notifications: |
|||
slack: npm-inc:kRqQjto7YbINqHPb1X6nS3g8 |
|||
|
|||
File diff suppressed because it is too large
@ -1,2 +1,6 @@ |
|||
#!/usr/bin/env sh |
|||
node "`dirname "$0"`/../../node_modules/node-gyp/bin/node-gyp.js" "$@" |
|||
if [ "x$npm_config_node_gyp" = "x" ]; then |
|||
node "`dirname "$0"`/../../node_modules/node-gyp/bin/node-gyp.js" "$@" |
|||
else |
|||
"$npm_config_node_gyp" "$@" |
|||
fi |
|||
|
|||
@ -1 +1,5 @@ |
|||
node "%~dp0\..\..\node_modules\node-gyp\bin\node-gyp.js" %* |
|||
if not defined npm_config_node_gyp ( |
|||
node "%~dp0\..\..\node_modules\node-gyp\bin\node-gyp.js" %* |
|||
) else ( |
|||
node "%npm_config_node_gyp%" %* |
|||
) |
|||
|
|||
@ -1,6 +1,19 @@ |
|||
:: Created by npm, please don't edit manually. |
|||
@IF EXIST "%~dp0\node.exe" ( |
|||
"%~dp0\node.exe" "%~dp0\.\node_modules\npm\bin\npm-cli.js" %* |
|||
) ELSE ( |
|||
node "%~dp0\.\node_modules\npm\bin\npm-cli.js" %* |
|||
) |
|||
:: Created by npm, please don't edit manually. |
|||
@ECHO OFF |
|||
|
|||
SETLOCAL |
|||
|
|||
SET "NODE_EXE=%~dp0\node.exe" |
|||
IF NOT EXIST "%NODE_EXE%" ( |
|||
SET "NODE_EXE=node" |
|||
) |
|||
|
|||
SET "NPM_CLI_JS=%~dp0\node_modules\npm\bin\npm-cli.js" |
|||
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_CLI_JS%" prefix -g') DO ( |
|||
SET "NPM_PREFIX_NPM_CLI_JS=%%F\node_modules\npm\bin\npm-cli.js" |
|||
) |
|||
IF EXIST "%NPM_PREFIX_NPM_CLI_JS%" ( |
|||
SET "NPM_CLI_JS=%NPM_PREFIX_NPM_CLI_JS%" |
|||
) |
|||
|
|||
"%NODE_EXE%" "%NPM_CLI_JS%" %* |
|||
|
|||
@ -0,0 +1,14 @@ |
|||
npm-ping(3) -- Ping npm registry |
|||
================================ |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm.registry.ping(registry, options, function (er, pong)) |
|||
|
|||
## DESCRIPTION |
|||
|
|||
Attempts to connect to the given registry, returning a `pong` |
|||
object with various metadata if it succeeds. |
|||
|
|||
This function is primarily useful for debugging connection issues |
|||
to npm registries. |
|||
@ -1,28 +0,0 @@ |
|||
npm-submodule(3) -- Add a package as a git submodule |
|||
==================================================== |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm.commands.submodule(packages, callback) |
|||
|
|||
## DESCRIPTION |
|||
|
|||
For each package specified, npm will check if it has a git repository url |
|||
in its package.json description then add it as a git submodule at |
|||
`node_modules/<pkg name>`. |
|||
|
|||
This is a convenience only. From then on, it's up to you to manage |
|||
updates by using the appropriate git commands. npm will stubbornly |
|||
refuse to update, modify, or remove anything with a `.git` subfolder |
|||
in it. |
|||
|
|||
This command also does not install missing dependencies, if the package |
|||
does not include them in its git repository. If `npm ls` reports that |
|||
things are missing, you can either install, link, or submodule them yourself, |
|||
or you can do `npm explore <pkgname> -- npm install` to install the |
|||
dependencies into the submodule folder. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm help json |
|||
* git help submodule |
|||
@ -0,0 +1,74 @@ |
|||
npm-access(1) -- Set access level on published packages |
|||
======================================================= |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm access public [<package>] |
|||
npm access restricted [<package>] |
|||
|
|||
npm access grant <read-only|read-write> <scope:team> [<package>] |
|||
npm access revoke <scope:team> [<package>] |
|||
|
|||
npm access ls-packages [<user>|<scope>|<scope:team>] |
|||
npm access ls-collaborators [<package> [<user>]] |
|||
npm access edit [<package>] |
|||
|
|||
## DESCRIPTION |
|||
|
|||
Used to set access controls on private packages. |
|||
|
|||
For all of the subcommands, `npm access` will perform actions on the packages |
|||
in the current working directory if no package name is passed to the |
|||
subcommand. |
|||
|
|||
* public / restricted: |
|||
Set a package to be either publicly accessible or restricted. |
|||
|
|||
* grant / revoke: |
|||
Add or remove the ability of users and teams to have read-only or read-write |
|||
access to a package. |
|||
|
|||
* ls-packages: |
|||
|
|||
Show all of the packages a user or a team is able to access, along with the |
|||
access level, except for read-only public packages (it won't print the whole |
|||
registry listing) |
|||
|
|||
* ls-collaborators: |
|||
Show all of the access privileges for a package. Will only show permissions |
|||
for packages to which you have at least read access. If `<user>` is passed in, |
|||
the list is filtered only to teams _that_ user happens to belong to. |
|||
|
|||
* edit: |
|||
Set the access privileges for a package at once using `$EDITOR`. |
|||
|
|||
## DETAILS |
|||
|
|||
`npm access` always operates directly on the current registry, configurable |
|||
from the command line using `--registry=<registry url>`. |
|||
|
|||
Unscoped packages are *always public*. |
|||
|
|||
Scoped packages *default to restricted*, but you can either publish them as |
|||
public using `npm publish --access=public`, or set their access as public using |
|||
`npm access public` after the initial publish. |
|||
|
|||
You must have privileges to set the access of a package: |
|||
|
|||
* You are an owner of an unscoped or scoped package. |
|||
* You are a member of the team that owns a scope. |
|||
* You have been given read-write privileges for a package, either as a member |
|||
of a team or directly as an owner. |
|||
|
|||
If your account is not paid, then attempts to publish scoped packages will fail |
|||
with an HTTP 402 status code (logically enough), unless you use |
|||
`--access=public`. |
|||
|
|||
Management of teams and team memberships is done with the `npm team` command. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-team(1) |
|||
* npm-publish(1) |
|||
* npm-config(7) |
|||
* npm-registry(7) |
|||
@ -0,0 +1,87 @@ |
|||
npm-dist-tag(1) -- Modify package distribution tags |
|||
=================================================== |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm dist-tag add <pkg>@<version> [<tag>] |
|||
npm dist-tag rm <pkg> <tag> |
|||
npm dist-tag ls [<pkg>] |
|||
|
|||
aliases: 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 if not specified. |
|||
|
|||
* rm: |
|||
Clear a tag that is no longer in use from the package. |
|||
|
|||
* ls: |
|||
Show all of the dist-tags for a package, defaulting to the package in |
|||
the current prefix. |
|||
|
|||
A tag can be used when installing packages as a reference to a version instead |
|||
of using a specific version number: |
|||
|
|||
npm install <name>@<tag> |
|||
|
|||
When installing dependencies, a preferred tagged version may be specified: |
|||
|
|||
npm install --tag <tag> |
|||
|
|||
This also applies to `npm dedupe`. |
|||
|
|||
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. |
|||
|
|||
By default, 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`. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-tag(1) |
|||
* npm-publish(1) |
|||
* npm-install(1) |
|||
* npm-dedupe(1) |
|||
* npm-registry(7) |
|||
* npm-config(1) |
|||
* npm-config(7) |
|||
* npmrc(5) |
|||
@ -0,0 +1,45 @@ |
|||
npm-logout(1) -- Log out of the registry |
|||
======================================== |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm logout [--registry=url] [--scope=@orgname] |
|||
|
|||
## DESCRIPTION |
|||
|
|||
When logged into a registry that supports token-based authentication, tell the |
|||
server to end this token's session. This will invalidate the token everywhere |
|||
you're using it, not just for the current environment. |
|||
|
|||
When logged into a legacy registry that uses username and password authentication, this will |
|||
clear the credentials in your user configuration. In this case, it will _only_ affect |
|||
the current environment. |
|||
|
|||
If `--scope` is provided, this will find the credentials for the registry |
|||
connected to that scope, if set. |
|||
|
|||
## CONFIGURATION |
|||
|
|||
### registry |
|||
|
|||
Default: https://registry.npmjs.org/ |
|||
|
|||
The base URL of the npm package registry. If `scope` is also specified, |
|||
it takes precedence. |
|||
|
|||
### scope |
|||
|
|||
Default: none |
|||
|
|||
If specified, you will be logged out of the specified scope. See `npm-scope(7)`. |
|||
|
|||
npm logout --scope=@myco |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-adduser(1) |
|||
* npm-registry(7) |
|||
* npm-config(1) |
|||
* npm-config(7) |
|||
* npmrc(5) |
|||
* npm-whoami(1) |
|||
@ -0,0 +1,16 @@ |
|||
npm-ping(1) -- Ping npm registry |
|||
================================ |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm ping [--registry <registry>] |
|||
|
|||
## DESCRIPTION |
|||
|
|||
Ping the configured or given npm registry and verify authentication. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-config(1) |
|||
* npm-config(7) |
|||
* npmrc(5) |
|||
@ -1,28 +0,0 @@ |
|||
npm-submodule(1) -- Add a package as a git submodule |
|||
==================================================== |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm submodule <pkg> |
|||
|
|||
## DESCRIPTION |
|||
|
|||
If the specified package has a git repository url in its package.json |
|||
description, then this command will add it as a git submodule at |
|||
`node_modules/<pkg name>`. |
|||
|
|||
This is a convenience only. From then on, it's up to you to manage |
|||
updates by using the appropriate git commands. npm will stubbornly |
|||
refuse to update, modify, or remove anything with a `.git` subfolder |
|||
in it. |
|||
|
|||
This command also does not install missing dependencies, if the package |
|||
does not include them in its git repository. If `npm ls` reports that |
|||
things are missing, you can either install, link, or submodule them yourself, |
|||
or you can do `npm explore <pkgname> -- npm install` to install the |
|||
dependencies into the submodule folder. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* package.json(5) |
|||
* git help submodule |
|||
@ -0,0 +1,55 @@ |
|||
npm-team(1) -- Manage organization teams and team memberships |
|||
============================================================= |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm team create <scope:team> |
|||
npm team destroy <scope:team> |
|||
|
|||
npm team add <scope:team> <user> |
|||
npm team rm <scope:team> <user> |
|||
|
|||
npm team ls <scope>|<scope:team> |
|||
|
|||
npm team edit <scope:team> |
|||
|
|||
## DESCRIPTION |
|||
|
|||
Used to manage teams in organizations, and change team memberships. Does not |
|||
handle permissions for packages. |
|||
|
|||
Teams must always be fully qualified with the organization/scope they belond to |
|||
when operating on them, separated by a colon (`:`). That is, if you have a |
|||
`developers` team on a `foo` organization, you must always refer to that team as |
|||
`foo:developers` in these commands. |
|||
|
|||
* create / destroy: |
|||
Create a new team, or destroy an existing one. |
|||
|
|||
* add / rm: |
|||
Add a user to an existing team, or remove a user from a team they belong to. |
|||
|
|||
* ls: |
|||
If performed on an organization name, will return a list of existing teams |
|||
under that organization. If performed on a team, it will instead return a list |
|||
of all users belonging to that particular team. |
|||
|
|||
## DETAILS |
|||
|
|||
`npm team` always operates directly on the current registry, configurable from |
|||
the command line using `--registry=<registry url>`. |
|||
|
|||
In order to create teams and manage team membership, you must be a *team admin* |
|||
under the given organization. Listing teams and team memberships may be done by |
|||
any member of the organizations. |
|||
|
|||
Organization creation and management of team admins and *organization* members |
|||
is done through the website, not the npm CLI. |
|||
|
|||
To use teams to manage permissions on packages belonging to your organization, |
|||
use the `npm access` command to grant or revoke the appropriate permissions. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-access(1) |
|||
* npm-registr(7) |
|||
@ -1,364 +0,0 @@ |
|||
npm-faq(7) -- Frequently Asked Questions |
|||
======================================== |
|||
|
|||
## Where can I find these docs in HTML? |
|||
|
|||
<https://www.npmjs.org/doc/>, or run: |
|||
|
|||
npm config set viewer browser |
|||
|
|||
to open these documents in your default web browser rather than `man`. |
|||
|
|||
## It didn't work. |
|||
|
|||
That's not really a question. |
|||
|
|||
## Why didn't it work? |
|||
|
|||
I don't know yet. |
|||
|
|||
Read the error output, and if you can't figure out what it means, |
|||
do what it says and post a bug with all the information it asks for. |
|||
|
|||
## Where does npm put stuff? |
|||
|
|||
See `npm-folders(5)` |
|||
|
|||
tl;dr: |
|||
|
|||
* Use the `npm root` command to see where modules go, and the `npm bin` |
|||
command to see where executables go |
|||
* Global installs are different from local installs. If you install |
|||
something with the `-g` flag, then its executables go in `npm bin -g` |
|||
and its modules go in `npm root -g`. |
|||
|
|||
## How do I install something on my computer in a central location? |
|||
|
|||
Install it globally by tacking `-g` or `--global` to the command. (This |
|||
is especially important for command line utilities that need to add |
|||
their bins to the global system `PATH`.) |
|||
|
|||
## I installed something globally, but I can't `require()` it |
|||
|
|||
Install it locally. |
|||
|
|||
The global install location is a place for command-line utilities |
|||
to put their bins in the system `PATH`. It's not for use with `require()`. |
|||
|
|||
If you `require()` a module in your code, then that means it's a |
|||
dependency, and a part of your program. You need to install it locally |
|||
in your program. |
|||
|
|||
## Why can't npm just put everything in one place, like other package managers? |
|||
|
|||
Not every change is an improvement, but every improvement is a change. |
|||
This would be like asking git to do network IO for every commit. It's |
|||
not going to happen, because it's a terrible idea that causes more |
|||
problems than it solves. |
|||
|
|||
It is much harder to avoid dependency conflicts without nesting |
|||
dependencies. This is fundamental to the way that npm works, and has |
|||
proven to be an extremely successful approach. See `npm-folders(5)` for |
|||
more details. |
|||
|
|||
If you want a package to be installed in one place, and have all your |
|||
programs reference the same copy of it, then use the `npm link` command. |
|||
That's what it's for. Install it globally, then link it into each |
|||
program that uses it. |
|||
|
|||
## Whatever, I really want the old style 'everything global' style. |
|||
|
|||
Write your own package manager. You could probably even wrap up `npm` |
|||
in a shell script if you really wanted to. |
|||
|
|||
npm will not help you do something that is known to be a bad idea. |
|||
|
|||
## Should I check my `node_modules` folder into git? |
|||
|
|||
Mikeal Rogers answered this question very well: |
|||
|
|||
<http://www.futurealoof.com/posts/nodemodules-in-git.html> |
|||
|
|||
tl;dr |
|||
|
|||
* Check `node_modules` into git for things you **deploy**, such as |
|||
websites and apps. |
|||
* Do not check `node_modules` into git for libraries and modules |
|||
intended to be reused. |
|||
* Use npm to manage dependencies in your dev environment, but not in |
|||
your deployment scripts. |
|||
|
|||
## Is it 'npm' or 'NPM' or 'Npm'? |
|||
|
|||
npm should never be capitalized unless it is being displayed in a |
|||
location that is customarily all-caps (such as the title of man pages.) |
|||
|
|||
## If 'npm' is an acronym, why is it never capitalized? |
|||
|
|||
Contrary to the belief of many, "npm" is not in fact an abbreviation for |
|||
"Node Package Manager". It is a recursive bacronymic abbreviation for |
|||
"npm is not an acronym". (If it was "ninaa", then it would be an |
|||
acronym, and thus incorrectly named.) |
|||
|
|||
"NPM", however, *is* an acronym (more precisely, a capitonym) for the |
|||
National Association of Pastoral Musicians. You can learn more |
|||
about them at <http://npm.org/>. |
|||
|
|||
In software, "NPM" is a Non-Parametric Mapping utility written by |
|||
Chris Rorden. You can analyze pictures of brains with it. Learn more |
|||
about the (capitalized) NPM program at <http://www.cabiatl.com/mricro/npm/>. |
|||
|
|||
The first seed that eventually grew into this flower was a bash utility |
|||
named "pm", which was a shortened descendent of "pkgmakeinst", a |
|||
bash function that was used to install various different things on different |
|||
platforms, most often using Yahoo's `yinst`. If `npm` was ever an |
|||
acronym for anything, it was `node pm` or maybe `new pm`. |
|||
|
|||
So, in all seriousness, the "npm" project is named after its command-line |
|||
utility, which was organically selected to be easily typed by a right-handed |
|||
programmer using a US QWERTY keyboard layout, ending with the |
|||
right-ring-finger in a postition to type the `-` key for flags and |
|||
other command-line arguments. That command-line utility is always |
|||
lower-case, though it starts most sentences it is a part of. |
|||
|
|||
## How do I list installed packages? |
|||
|
|||
`npm ls` |
|||
|
|||
## How do I search for packages? |
|||
|
|||
`npm search` |
|||
|
|||
Arguments are greps. `npm search jsdom` shows jsdom packages. |
|||
|
|||
## How do I update npm? |
|||
|
|||
npm update npm -g |
|||
|
|||
You can also update all outdated local packages by doing `npm update` without |
|||
any arguments, or global packages by doing `npm update -g`. |
|||
|
|||
Occasionally, the version of npm will progress such that the current |
|||
version cannot be properly installed with the version that you have |
|||
installed already. (Consider, if there is ever a bug in the `update` |
|||
command.) |
|||
|
|||
In those cases, you can do this: |
|||
|
|||
curl https://www.npmjs.org/install.sh | sh |
|||
|
|||
## What is a `package`? |
|||
|
|||
A package is: |
|||
|
|||
* a) a folder containing a program described by a package.json file |
|||
* b) a gzipped tarball containing (a) |
|||
* c) a url that resolves to (b) |
|||
* d) a `<name>@<version>` that is published on the registry with (c) |
|||
* e) a `<name>@<tag>` that points to (d) |
|||
* f) a `<name>` that has a "latest" tag satisfying (e) |
|||
* g) a `git` url that, when cloned, results in (a). |
|||
|
|||
Even if you never publish your package, you can still get a lot of |
|||
benefits of using npm if you just want to write a node program (a), and |
|||
perhaps if you also want to be able to easily install it elsewhere |
|||
after packing it up into a tarball (b). |
|||
|
|||
Git urls can be of the form: |
|||
|
|||
git://github.com/user/project.git#commit-ish |
|||
git+ssh://user@hostname:project.git#commit-ish |
|||
git+http://user@hostname/project/blah.git#commit-ish |
|||
git+https://user@hostname/project/blah.git#commit-ish |
|||
|
|||
The `commit-ish` can be any tag, sha, or branch which can be supplied as |
|||
an argument to `git checkout`. The default is `master`. |
|||
|
|||
## What is a `module`? |
|||
|
|||
A module is anything that can be loaded with `require()` in a Node.js |
|||
program. The following things are all examples of things that can be |
|||
loaded as modules: |
|||
|
|||
* A folder with a `package.json` file containing a `main` field. |
|||
* A folder with an `index.js` file in it. |
|||
* A JavaScript file. |
|||
|
|||
Most npm packages are modules, because they are libraries that you |
|||
load with `require`. However, there's no requirement that an npm |
|||
package be a module! Some only contain an executable command-line |
|||
interface, and don't provide a `main` field for use in Node programs. |
|||
|
|||
Almost all npm packages (at least, those that are Node programs) |
|||
*contain* many modules within them (because every file they load with |
|||
`require()` is a module). |
|||
|
|||
In the context of a Node program, the `module` is also the thing that |
|||
was loaded *from* a file. For example, in the following program: |
|||
|
|||
var req = require('request') |
|||
|
|||
we might say that "The variable `req` refers to the `request` module". |
|||
|
|||
## So, why is it the "`node_modules`" folder, but "`package.json`" file? Why not `node_packages` or `module.json`? |
|||
|
|||
The `package.json` file defines the package. (See "What is a |
|||
package?" above.) |
|||
|
|||
The `node_modules` folder is the place Node.js looks for modules. |
|||
(See "What is a module?" above.) |
|||
|
|||
For example, if you create a file at `node_modules/foo.js` and then |
|||
had a program that did `var f = require('foo.js')` then it would load |
|||
the module. However, `foo.js` is not a "package" in this case, |
|||
because it does not have a package.json. |
|||
|
|||
Alternatively, if you create a package which does not have an |
|||
`index.js` or a `"main"` field in the `package.json` file, then it is |
|||
not a module. Even if it's installed in `node_modules`, it can't be |
|||
an argument to `require()`. |
|||
|
|||
## `"node_modules"` is the name of my deity's arch-rival, and a Forbidden Word in my religion. Can I configure npm to use a different folder? |
|||
|
|||
No. This will never happen. This question comes up sometimes, |
|||
because it seems silly from the outside that npm couldn't just be |
|||
configured to put stuff somewhere else, and then npm could load them |
|||
from there. It's an arbitrary spelling choice, right? What's the big |
|||
deal? |
|||
|
|||
At the time of this writing, the string `'node_modules'` appears 151 |
|||
times in 53 separate files in npm and node core (excluding tests and |
|||
documentation). |
|||
|
|||
Some of these references are in node's built-in module loader. Since |
|||
npm is not involved **at all** at run-time, node itself would have to |
|||
be configured to know where you've decided to stick stuff. Complexity |
|||
hurdle #1. Since the Node module system is locked, this cannot be |
|||
changed, and is enough to kill this request. But I'll continue, in |
|||
deference to your deity's delicate feelings regarding spelling. |
|||
|
|||
Many of the others are in dependencies that npm uses, which are not |
|||
necessarily tightly coupled to npm (in the sense that they do not read |
|||
npm's configuration files, etc.) Each of these would have to be |
|||
configured to take the name of the `node_modules` folder as a |
|||
parameter. Complexity hurdle #2. |
|||
|
|||
Furthermore, npm has the ability to "bundle" dependencies by adding |
|||
the dep names to the `"bundledDependencies"` list in package.json, |
|||
which causes the folder to be included in the package tarball. What |
|||
if the author of a module bundles its dependencies, and they use a |
|||
different spelling for `node_modules`? npm would have to rename the |
|||
folder at publish time, and then be smart enough to unpack it using |
|||
your locally configured name. Complexity hurdle #3. |
|||
|
|||
Furthermore, what happens when you *change* this name? Fine, it's |
|||
easy enough the first time, just rename the `node_modules` folders to |
|||
`./blergyblerp/` or whatever name you choose. But what about when you |
|||
change it again? npm doesn't currently track any state about past |
|||
configuration settings, so this would be rather difficult to do |
|||
properly. It would have to track every previous value for this |
|||
config, and always accept any of them, or else yesterday's install may |
|||
be broken tomorrow. Complexity hurdle #4. |
|||
|
|||
Never going to happen. The folder is named `node_modules`. It is |
|||
written indelibly in the Node Way, handed down from the ancient times |
|||
of Node 0.3. |
|||
|
|||
## How do I install node with npm? |
|||
|
|||
You don't. Try one of these node version managers: |
|||
|
|||
Unix: |
|||
|
|||
* <http://github.com/isaacs/nave> |
|||
* <http://github.com/visionmedia/n> |
|||
* <http://github.com/creationix/nvm> |
|||
|
|||
Windows: |
|||
|
|||
* <http://github.com/marcelklehr/nodist> |
|||
* <https://github.com/hakobera/nvmw> |
|||
* <https://github.com/nanjingboy/nvmw> |
|||
|
|||
## How can I use npm for development? |
|||
|
|||
See `npm-developers(7)` and `package.json(5)`. |
|||
|
|||
You'll most likely want to `npm link` your development folder. That's |
|||
awesomely handy. |
|||
|
|||
To set up your own private registry, check out `npm-registry(7)`. |
|||
|
|||
## Can I list a url as a dependency? |
|||
|
|||
Yes. It should be a url to a gzipped tarball containing a single folder |
|||
that has a package.json in its root, or a git url. |
|||
(See "what is a package?" above.) |
|||
|
|||
## How do I symlink to a dev folder so I don't have to keep re-installing? |
|||
|
|||
See `npm-link(1)` |
|||
|
|||
## The package registry website. What is that exactly? |
|||
|
|||
See `npm-registry(7)`. |
|||
|
|||
## I forgot my password, and can't publish. How do I reset it? |
|||
|
|||
Go to <https://npmjs.org/forgot>. |
|||
|
|||
## I get ECONNREFUSED a lot. What's up? |
|||
|
|||
Either the registry is down, or node's DNS isn't able to reach out. |
|||
|
|||
To check if the registry is down, open up |
|||
<https://registry.npmjs.org/> in a web browser. This will also tell |
|||
you if you are just unable to access the internet for some reason. |
|||
|
|||
If the registry IS down, let us know by emailing <support@npmjs.com> |
|||
or posting an issue at <https://github.com/npm/npm/issues>. If it's |
|||
down for the world (and not just on your local network) then we're |
|||
probably already being pinged about it. |
|||
|
|||
You can also often get a faster response by visiting the #npm channel |
|||
on Freenode IRC. |
|||
|
|||
## Why no namespaces? |
|||
|
|||
Please see this discussion: <https://github.com/npm/npm/issues/798> |
|||
|
|||
tl;dr - It doesn't actually make things better, and can make them worse. |
|||
|
|||
If you want to namespace your own packages, you may: simply use the |
|||
`-` character to separate the names. npm is a mostly anarchic system. |
|||
There is not sufficient need to impose namespace rules on everyone. |
|||
|
|||
## Who does npm? |
|||
|
|||
npm was originally written by Isaac Z. Schlueter, and many others have |
|||
contributed to it, some of them quite substantially. |
|||
|
|||
The npm open source project, The npm Registry, and [the community |
|||
website](https://www.npmjs.org) are maintained and operated by the |
|||
good folks at [npm, Inc.](http://www.npmjs.com) |
|||
|
|||
## I have a question or request not addressed here. Where should I put it? |
|||
|
|||
Post an issue on the github project: |
|||
|
|||
* <https://github.com/npm/npm/issues> |
|||
|
|||
## Why does npm hate me? |
|||
|
|||
npm is not capable of hatred. It loves everyone, especially you. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm(1) |
|||
* npm-developers(7) |
|||
* package.json(5) |
|||
* npm-config(1) |
|||
* npm-config(7) |
|||
* npmrc(5) |
|||
* npm-config(7) |
|||
* npm-folders(5) |
|||
@ -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-access(1) for more details |
|||
2. `npm access` see npm-team(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) |
|||
@ -0,0 +1,105 @@ |
|||
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, 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. |
|||
|
|||
Scoped packages are supported by the public npm registry. The npm |
|||
client is backwards-compatible with un-scoped registries, so it can be |
|||
used to work with scoped and un-scoped 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 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 is |
|||
just specifying to require the module `mypackage` in the folder called `@myorg`. |
|||
|
|||
## Publishing scoped packages |
|||
|
|||
Scoped packages can be published to any registry that supports them, including |
|||
the public npm registry. |
|||
|
|||
(As of 2015-04-19, and with npm 2.0 or newer, the public 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 public 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 public 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) |
|||
@ -0,0 +1,32 @@ |
|||
<!doctype html> |
|||
<html> |
|||
<title>npm-ping</title> |
|||
<meta http-equiv="content-type" value="text/html;utf-8"> |
|||
<link rel="stylesheet" type="text/css" href="../../static/style.css"> |
|||
<link rel="canonical" href="https://www.npmjs.org/doc/api/npm-ping.html"> |
|||
<script async=true src="../../static/toc.js"></script> |
|||
|
|||
<body> |
|||
<div id="wrapper"> |
|||
|
|||
<h1><a href="../api/npm-ping.html">npm-ping</a></h1> <p>Ping npm registry</p> |
|||
<h2 id="synopsis">SYNOPSIS</h2> |
|||
<pre><code>npm.registry.ping(registry, options, function (er, pong)) |
|||
</code></pre><h2 id="description">DESCRIPTION</h2> |
|||
<p>Attempts to connect to the given registry, returning a <code>pong</code> |
|||
object with various metadata if it succeeds.</p> |
|||
<p>This function is primarily useful for debugging connection issues |
|||
to npm registries.</p> |
|||
|
|||
</div> |
|||
|
|||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo> |
|||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr> |
|||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr> |
|||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr> |
|||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr> |
|||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr> |
|||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr> |
|||
</table> |
|||
<p id="footer">npm-ping — npm@2.15.0</p> |
|||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue