mirror of
https://github.com/titanscouting/tra-analysis.git
synced 2025-09-28 07:50:18 +00:00
push all website files
This commit is contained in:
Jacob Levine
9
website/node_modules/npm/.licensee.json
generated
vendored
Normal file
9
website/node_modules/npm/.licensee.json
generated
vendored
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"license": "(MIT OR BSD-2-Clause OR BSD-3-Clause OR Apache-2.0 OR ISC OR Unlicense OR CC-BY-3.0 OR CC0-1.0 OR Artistic-2.0)",
|
||||
"whitelist": {
|
||||
"config-chain": "1.1.12",
|
||||
"cyclist": "0.2.2",
|
||||
"json-schema": "0.2.3",
|
||||
"qrcode-terminal": "0.12.0"
|
||||
}
|
||||
}
|
||||
74
website/node_modules/npm/.mailmap
generated
vendored
Normal file
74
website/node_modules/npm/.mailmap
generated
vendored
Normal file
@@ -0,0 +1,74 @@
|
||||
Alex K. Wolfe <alexkwolfe@gmail.com>
|
||||
Andrew Bradley <cspotcode@gmail.com>
|
||||
Andrew Lunny <alunny@gmail.com>
|
||||
Arlo Breault <arlolra@gmail.com>
|
||||
Ashley Williams <ashley@npmjs.com> <ashley@bocoup.com>
|
||||
Ashley Williams <ashley@npmjs.com> <ashley666ashley@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>
|
||||
Dave Galbraith <dave@jut.io>
|
||||
David Beitey <david@davidjb.com>
|
||||
David Rousselie <guido.dassori@gmail.com>
|
||||
Domenic Denicola <domenic@domenicdenicola.com>
|
||||
Einar Otto Stangvik <einaros@gmail.com>
|
||||
Emma Ramirez <ramirez.emma.g@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> <othiym23@gmail.com>
|
||||
Gabriel Barros <descartavel1@gmail.com>
|
||||
Geoff Flarity <geoff.flarity@gmail.com> <gflarity@raptvm-x02.(none)>
|
||||
Gregers Gram Rygg <gregers.gram.rygg@finn.no>
|
||||
Ifeanyi Oraelosi <ifeanyioraelosi@gmail.com>
|
||||
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>
|
||||
James Treworgy <jamietre@gmail.com>
|
||||
Jason Smith <jhs@iriscouch.com>
|
||||
Jed Fox <git@twopointzero.us>
|
||||
Joshua Bennett <legodudejb@gmail.com>
|
||||
Joshua Bennett <legodudejb@gmail.com> <legodude17@users.noreply.github.com>
|
||||
Jonas Weber <github@jonasw.de>
|
||||
Julien Meddah <julien.meddah@deveryware.com>
|
||||
Kat Marchán <kzm@zkat.tech> <kzm@sykosomatic.org>
|
||||
Kevin Lorenz <mail@kevinlorenz.com>
|
||||
Kris Windham <kriswindham@gmail.com>
|
||||
Leonardo Rojas <leonardo.rojas@shopify.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>
|
||||
Martin Ek <mail@ekmartin.com>
|
||||
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>
|
||||
Misha Kaletsky <misha.kaletsky@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>
|
||||
Sreenivas Alapati <sreenivas9alapati@gmail.com>
|
||||
Stephanie Snopek <stephaniesnopek@gmail.com>
|
||||
Takaya Kobayashi <jigsaw@live.jp>
|
||||
Ted Yavuzkurt <hello@TedY.io> <davidteoman@gmail.com>
|
||||
Thomas Reggi <thomas@reggi.com>
|
||||
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>
|
||||
Zoujie Wzj <zoujie.wzj@alibaba-inc.com>
|
||||
26
website/node_modules/npm/.npmignore
generated
vendored
Normal file
26
website/node_modules/npm/.npmignore
generated
vendored
Normal file
@@ -0,0 +1,26 @@
|
||||
*.swp
|
||||
.*.swp
|
||||
npm-debug.log
|
||||
/.github
|
||||
/test
|
||||
node_modules/marked
|
||||
node_modules/ronn
|
||||
node_modules/tap
|
||||
node_modules/.bin
|
||||
node_modules/npm-registry-mock
|
||||
/npmrc
|
||||
/release/
|
||||
|
||||
# don't need these in the npm package.
|
||||
html/*.png
|
||||
|
||||
# don't ignore .npmignore files
|
||||
# these are used in some tests.
|
||||
!.npmignore
|
||||
|
||||
/npm-*.tgz
|
||||
|
||||
*.pyc
|
||||
|
||||
|
||||
.nyc_output
|
||||
38
website/node_modules/npm/.travis.yml
generated
vendored
Normal file
38
website/node_modules/npm/.travis.yml
generated
vendored
Normal file
@@ -0,0 +1,38 @@
|
||||
sudo: false
|
||||
# need to declare the language as well as the matrix below
|
||||
language: node_js
|
||||
# having top-level `env:` adds a phantom build
|
||||
# https://github.com/travis-ci/travis-ci/issues/4681
|
||||
#env: DEPLOY_VERSION=testing
|
||||
matrix:
|
||||
include:
|
||||
# LTS is our most important target
|
||||
- node_js: "10"
|
||||
# DEPLOY_VERSION is used to set the couchapp setup mode for test/tap/registry.js
|
||||
# only gather coverage info for LTS
|
||||
env: DEPLOY_VERSION=testing COVERALLS_REPO_TOKEN="$COVERALLS_OPTIONAL_TOKEN"
|
||||
script:
|
||||
- "node . run tap-cover -- \"test/tap/*.js\""
|
||||
- "unset COVERALLS_REPO_TOKEN ; node . run tap -- \"test/broken-under-*/*.js\""
|
||||
# previous LTS is next most important
|
||||
- node_js: "6"
|
||||
env: DEPLOY_VERSION=testing
|
||||
- node_js: "8"
|
||||
env: DEPLOY_VERSION=testing
|
||||
- node_js: "9"
|
||||
env: DEPLOY_VERSION=testing
|
||||
- node_js: "11"
|
||||
env: DEPLOY_VERSION=testing
|
||||
script:
|
||||
- "npx standard"
|
||||
- "node . run licenses"
|
||||
- "node . run tap -- \"test/tap/*.js\" \"test/broken-under-nyc/*.js\""
|
||||
notifications:
|
||||
slack: npm-inc:kRqQjto7YbINqHPb1X6nS3g8
|
||||
cache:
|
||||
directories:
|
||||
- node_modules/.cache
|
||||
install:
|
||||
- "node . install"
|
||||
script:
|
||||
- "node . run tap -- \"test/tap/*.js\" \"test/broken-under-nyc/*.js\""
|
||||
614
website/node_modules/npm/AUTHORS
generated
vendored
Normal file
614
website/node_modules/npm/AUTHORS
generated
vendored
Normal file
@@ -0,0 +1,614 @@
|
||||
# Authors sorted by whether or not they're me
|
||||
Isaac Z. Schlueter <i@izs.me>
|
||||
Steve Steiner <ssteinerX@gmail.com>
|
||||
Mikeal Rogers <mikeal.rogers@gmail.com>
|
||||
Aaron Blohowiak <aaron.blohowiak@gmail.com>
|
||||
Martyn Smith <martyn@dollyfish.net.nz>
|
||||
Charlie Robbins <charlie.robbins@gmail.com>
|
||||
Francisco Treacy <francisco.treacy@gmail.com>
|
||||
Cliffano Subagio <cliffano@gmail.com>
|
||||
Christian Eager <christian.eager@nokia.com>
|
||||
Dav Glass <davglass@gmail.com>
|
||||
Alex K. Wolfe <alexkwolfe@gmail.com>
|
||||
James Sanders <jimmyjazz14@gmail.com>
|
||||
Reid Burke <me@reidburke.com>
|
||||
Arlo Breault <arlolra@gmail.com>
|
||||
Timo Derstappen <teemow@gmail.com>
|
||||
Bart Teeuwisse <bart.teeuwisse@thecodemill.biz>
|
||||
Ben Noordhuis <info@bnoordhuis.nl>
|
||||
Tor Valamo <tor.valamo@gmail.com>
|
||||
Whyme.Lyu <5longluna@gmail.com>
|
||||
Olivier Melcher <olivier.melcher@gmail.com>
|
||||
Tomaž Muraus <kami@k5-storitve.net>
|
||||
Evan Meagher <evan.meagher@gmail.com>
|
||||
Orlando Vazquez <ovazquez@gmail.com>
|
||||
Kai Chen <kaichenxyz@gmail.com>
|
||||
George Miroshnykov <gmiroshnykov@lohika.com>
|
||||
Geoff Flarity <geoff.flarity@gmail.com>
|
||||
Max Goodman <c@chromakode.com>
|
||||
Pete Kruckenberg <pete@kruckenberg.com>
|
||||
Laurie Harper <laurie@holoweb.net>
|
||||
Chris Wong <chris@chriswongstudio.com>
|
||||
Scott Bronson <brons_github@rinspin.com>
|
||||
Federico Romero <federomero@gmail.com>
|
||||
Visnu Pitiyanuvath <visnupx@gmail.com>
|
||||
Irakli Gozalishvili <rfobic@gmail.com>
|
||||
Mark Cahill <mark@tiemonster.info>
|
||||
Tony <zearin@gonk.net>
|
||||
Iain Sproat <iainsproat@gmail.com>
|
||||
Trent Mick <trentm@gmail.com>
|
||||
Felix Geisendörfer <felix@debuggable.com>
|
||||
Jameson Little <t.jameson.little@gmail.com>
|
||||
Conny Brunnkvist <conny@fuchsia.se>
|
||||
Will Elwood <w.elwood08@gmail.com>
|
||||
Dean Landolt <dean@deanlandolt.com>
|
||||
Oleg Efimov <efimovov@gmail.com>
|
||||
Martin Cooper <mfncooper@gmail.com>
|
||||
Jann Horn <jannhorn@googlemail.com>
|
||||
Andrew Bradley <cspotcode@gmail.com>
|
||||
Maciej Małecki <me@mmalecki.com>
|
||||
Stephen Sugden <glurgle@gmail.com>
|
||||
Michael Budde <mbudde@gmail.com>
|
||||
Jason Smith <jhs@iriscouch.com>
|
||||
Gautham Pai <buzypi@gmail.com>
|
||||
David Trejo <david.daniel.trejo@gmail.com>
|
||||
Paul Vorbach <paul@vorb.de>
|
||||
George Ornbo <george@shapeshed.com>
|
||||
Tim Oxley <secoif@gmail.com>
|
||||
Tyler Green <tyler.green2@gmail.com>
|
||||
Dave Pacheco <dap@joyent.com>
|
||||
Danila Gerasimov <danila.gerasimov@gmail.com>
|
||||
Rod Vagg <rod@vagg.org>
|
||||
Christian Howe <coderarity@gmail.com>
|
||||
Andrew Lunny <alunny@gmail.com>
|
||||
Henrik Hodne <dvyjones@binaryhex.com>
|
||||
Adam Blackburn <regality@gmail.com>
|
||||
Kris Windham <kriswindham@gmail.com>
|
||||
Jens Grunert <jens.grunert@gmail.com>
|
||||
Joost-Wim Boekesteijn <joost-wim@boekesteijn.nl>
|
||||
Dalmais Maxence <root@ip-10-195-202-5.ec2.internal>
|
||||
Marcus Ekwall <marcus.ekwall@gmail.com>
|
||||
Aaron Stacy <aaron.r.stacy@gmail.com>
|
||||
Phillip Howell <phowell@cothm.org>
|
||||
Domenic Denicola <domenic@domenicdenicola.com>
|
||||
James Halliday <mail@substack.net>
|
||||
Jeremy Cantrell <jmcantrell@gmail.com>
|
||||
Ribettes <patlogan29@gmail.com>
|
||||
Don Park <donpark@docuverse.com>
|
||||
Einar Otto Stangvik <einaros@gmail.com>
|
||||
Kei Son <heyacct@gmail.com>
|
||||
Nicolas Morel <marsup@gmail.com>
|
||||
Mark Dube <markisdee@gmail.com>
|
||||
Nathan Rajlich <nathan@tootallnate.net>
|
||||
Maxim Bogushevich <boga1@mail.ru>
|
||||
Meaglin <Meaglin.wasabi@gmail.com>
|
||||
Ben Evans <ben@bensbit.co.uk>
|
||||
Nathan Zadoks <nathan@nathan7.eu>
|
||||
Brian White <mscdex@mscdex.net>
|
||||
Jed Schmidt <tr@nslator.jp>
|
||||
Ian Livingstone <ianl@cs.dal.ca>
|
||||
Patrick Pfeiffer <patrick@buzzle.at>
|
||||
Paul Miller <paul@paulmillr.com>
|
||||
Ryan Emery <seebees@gmail.com>
|
||||
Carl Lange <carl@flax.ie>
|
||||
Jan Lehnardt <jan@apache.org>
|
||||
Stuart P. Bentley <stuart@testtrack4.com>
|
||||
Johan Sköld <johan@skold.cc>
|
||||
Stuart Knightley <stuart@stuartk.com>
|
||||
Niggler <nirk.niggler@gmail.com>
|
||||
Paolo Fragomeni <paolo@async.ly>
|
||||
Jaakko Manninen <jaakko@rocketpack.fi>
|
||||
Luke Arduini <luke.arduini@gmail.com>
|
||||
Larz Conwell <larz@larz-laptop.(none)>
|
||||
Marcel Klehr <mklehr@gmx.net>
|
||||
Robert Kowalski <rok@kowalski.gd>
|
||||
Forbes Lindesay <forbes@lindesay.co.uk>
|
||||
Vaz Allen <vaz@tryptid.com>
|
||||
Jake Verbaten <raynos2@gmail.com>
|
||||
Schabse Laks <Dev@SLaks.net>
|
||||
Florian Margaine <florian@margaine.com>
|
||||
Johan Nordberg <its@johan-nordberg.com>
|
||||
Ian Babrou <ibobrik@gmail.com>
|
||||
Di Wu <dwu@palantir.com>
|
||||
Mathias Bynens <mathias@qiwi.be>
|
||||
Matt McClure <matt.mcclure@mapmyfitness.com>
|
||||
Matt Lunn <matt@mattlunn.me.uk>
|
||||
Alexey Kreschuk <akrsch@gmail.com>
|
||||
elisee <elisee@sparklin.org>
|
||||
Robert Gieseke <robert.gieseke@gmail.com>
|
||||
François Frisch <francoisfrisch@gmail.com>
|
||||
Trevor Burnham <tburnham@hubspot.com>
|
||||
Alan Shaw <alan@freestyle-developments.co.uk>
|
||||
TJ Holowaychuk <tj@vision-media.ca>
|
||||
Nicholas Kinsey <pyro@feisty.io>
|
||||
Paulo Cesar <pauloc062@gmail.com>
|
||||
Elan Shanker <elan.shanker@gmail.com>
|
||||
Jon Spencer <jon@jonspencer.ca>
|
||||
Jason Diamond <jason@diamond.name>
|
||||
Maximilian Antoni <mail@maxantoni.de>
|
||||
Thom Blake <tblake@brightroll.com>
|
||||
Jess Martin <jessmartin@gmail.com>
|
||||
Spain Train <michael.spainhower@opower.com>
|
||||
Alex Rodionov <p0deje@gmail.com>
|
||||
Matt Colyer <matt@colyer.name>
|
||||
Evan You <yyx990803@gmail.com>
|
||||
bitspill <bitspill+github@bitspill.net>
|
||||
Gabriel Falkenberg <gabriel.falkenberg@gmail.com>
|
||||
Alexej Yaroshevich <alex@qfox.ru>
|
||||
Quim Calpe <quim@kalpe.com>
|
||||
Steve Mason <stevem@brandwatch.com>
|
||||
Wil Moore III <wil.moore@wilmoore.com>
|
||||
Sergey Belov <peimei@ya.ru>
|
||||
Tom Huang <hzlhu.dargon@gmail.com>
|
||||
CamilleM <camille.moulin@alterway.fr>
|
||||
Sébastien Santoro <dereckson@espace-win.org>
|
||||
Evan Lucas <evan@btc.com>
|
||||
Quinn Slack <qslack@qslack.com>
|
||||
Alex Kocharin <alex@kocharin.ru>
|
||||
Daniel Santiago <daniel.santiago@highlevelwebs.com>
|
||||
Denis Gladkikh <outcoldman@gmail.com>
|
||||
Andrew Horton <andrew.j.horton@gmail.com>
|
||||
Zeke Sikelianos <zeke@sikelianos.com>
|
||||
Dylan Greene <dylang@gmail.com>
|
||||
Franck Cuny <franck.cuny@gmail.com>
|
||||
Yeonghoon Park <sola92@gmail.com>
|
||||
Rafael de Oleza <rafa@spotify.com>
|
||||
Mikola Lysenko <mikolalysenko@gmail.com>
|
||||
Yazhong Liu <yorkiefixer@gmail.com>
|
||||
Neil Gentleman <ngentleman@gmail.com>
|
||||
Kris Kowal <kris.kowal@cixar.com>
|
||||
Alex Gorbatchev <alex.gorbatchev@gmail.com>
|
||||
Shawn Wildermuth <shawn@wildermuth.com>
|
||||
Wesley de Souza <wesleywex@gmail.com>
|
||||
yoyoyogi <yogesh.k@gmail.com>
|
||||
J. Tangelder <j.tangelder@gmail.com>
|
||||
Jean Lauliac <jean@lauliac.com>
|
||||
Andrey Kislyuk <kislyuk@gmail.com>
|
||||
Thorsten Lorenz <thlorenz@gmx.de>
|
||||
Julian Gruber <julian@juliangruber.com>
|
||||
Benjamin Coe <bencoe@gmail.com>
|
||||
Alex Ford <Alex.Ford@CodeTunnel.com>
|
||||
Matt Hickford <matt.hickford@gmail.com>
|
||||
Sean McGivern <sean.mcgivern@rightscale.com>
|
||||
C J Silverio <ceejceej@gmail.com>
|
||||
Robin Tweedie <robin@songkick.com>
|
||||
Miroslav Bajtoš <miroslav@strongloop.com>
|
||||
David Glasser <glasser@davidglasser.net>
|
||||
Gianluca Casati <casati_gianluca@yahoo.it>
|
||||
Forrest L Norvell <ogd@aoaioxxysz.net>
|
||||
Karsten Tinnefeld <k.tinnefeld@googlemail.com>
|
||||
Bryan Burgers <bryan@burgers.io>
|
||||
David Beitey <david@davidjb.com>
|
||||
Evan You <yyou@google.com>
|
||||
Zach Pomerantz <zmp@umich.edu>
|
||||
Chris Williams <cwilliams88@gmail.com>
|
||||
sudodoki <smd.deluzion@gmail.com>
|
||||
Mick Thompson <dthompson@gmail.com>
|
||||
Felix Rabe <felix@rabe.io>
|
||||
Michael Hayes <michael@hayes.io>
|
||||
Chris Dickinson <christopher.s.dickinson@gmail.com>
|
||||
Bradley Meck <bradley.meck@gmail.com>
|
||||
GeJ <geraud@gcu.info>
|
||||
Andrew Terris <atterris@gmail.com>
|
||||
Michael Nisi <michael.nisi@gmail.com>
|
||||
fengmk2 <fengmk2@gmail.com>
|
||||
Adam Meadows <adam.meadows@gmail.com>
|
||||
Chulki Lee <chulki.lee@gmail.com>
|
||||
不四 <busi.hyy@taobao.com>
|
||||
dead_horse <dead_horse@qq.com>
|
||||
Kenan Yildirim <kenan@kenany.me>
|
||||
Laurie Voss <git@seldo.com>
|
||||
Rebecca Turner <me@re-becca.org>
|
||||
Hunter Loftis <hunter@hunterloftis.com>
|
||||
Peter Richardson <github@zoomy.net>
|
||||
Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
|
||||
Filip Weiss <me@fiws.net>
|
||||
Timo Weiß <timoweiss@Timo-MBP.local>
|
||||
Christopher Hiller <chiller@badwing.com>
|
||||
Jérémy Lal <kapouer@melix.org>
|
||||
Anders Janmyr <anders@janmyr.com>
|
||||
Chris Meyers <chris.meyers.fsu@gmail.com>
|
||||
Ludwig Magnusson <ludwig@mediatool.com>
|
||||
Wout Mertens <Wout.Mertens@gmail.com>
|
||||
Nick Santos <nick@medium.com>
|
||||
Terin Stock <terinjokes@gmail.com>
|
||||
Faiq Raza <faiqrazarizvi@gmail.com>
|
||||
Thomas Torp <thomas@erupt.no>
|
||||
Sam Mikes <smikes@cubane.com>
|
||||
Mat Tyndall <mat.tyndall@gmail.com>
|
||||
Tauren Mills <tauren@sportzing.com>
|
||||
Ron Martinez <ramartin.net@gmail.com>
|
||||
Kazuhito Hokamura <k.hokamura@gmail.com>
|
||||
Tristan Davies <github@tristan.io>
|
||||
David Volm <david@volminator.com>
|
||||
Lin Clark <lin.w.clark@gmail.com>
|
||||
Ben Page <bpage@dewalch.com>
|
||||
Jeff Jo <jeffjo@squareup.com>
|
||||
martinvd <martinvdpub@gmail.com>
|
||||
Mark J. Titorenko <nospam-github.com@titorenko.net>
|
||||
Oddur Sigurdsson <oddurs@gmail.com>
|
||||
Eric Mill <eric@konklone.com>
|
||||
Gabriel Barros <descartavel1@gmail.com>
|
||||
KevinSheedy <kevinsheedy@gmail.com>
|
||||
Aleksey Smolenchuk <aleksey@uber.com>
|
||||
Ed Morley <emorley@mozilla.com>
|
||||
Blaine Bublitz <blaine@iceddev.com>
|
||||
Andrey Fedorov <anfedorov@gmail.com>
|
||||
Daijiro Wachi <daijiro.wachi@gmail.com>
|
||||
Luc Thevenard <lucthevenard@gmail.com>
|
||||
Aria Stewart <aredridel@nbtsc.org>
|
||||
Charlie Rudolph <charles.w.rudolph@gmail.com>
|
||||
Vladimir Rutsky <rutsky@users.noreply.github.com>
|
||||
Isaac Murchie <isaac@saucelabs.com>
|
||||
Marcin Wosinek <marcin.wosinek@gmail.com>
|
||||
David Marr <davemarr@gmail.com>
|
||||
Bryan English <bryan@bryanenglish.com>
|
||||
Anthony Zotti <amZotti@users.noreply.github.com>
|
||||
Karl Horky <karl.horky@gmail.com>
|
||||
Jordan Harband <ljharb@gmail.com>
|
||||
Guðlaugur Stefán Egilsson <gulli@kolibri.is>
|
||||
Helge Skogly Holm <helge.holm@gmail.com>
|
||||
Peter A. Shevtsov <petr.shevtsov@gmail.com>
|
||||
Alain Kalker <a.c.kalker@gmail.com>
|
||||
Bryant Williams <b.n.williams@gmail.com>
|
||||
Jonas Weber <github@jonasw.de>
|
||||
Tim Whidden <twhid@twhid.com>
|
||||
Andreas <functino@users.noreply.github.com>
|
||||
Karolis Narkevicius <karolis.n@gmail.com>
|
||||
Adrian Lynch <adi_ady_ade@hotmail.com>
|
||||
Richard Littauer <richard.littauer@gmail.com>
|
||||
Oli Evans <oli@zilla.org.uk>
|
||||
Matt Brennan <mattyb1000@gmail.com>
|
||||
Jeff Barczewski <jeff.barczewski@gmail.com>
|
||||
Danny Fritz <dannyfritz@gmail.com>
|
||||
Takaya Kobayashi <jigsaw@live.jp>
|
||||
Ra'Shaun Stovall <rashaunstovall@gmail.com>
|
||||
Julien Meddah <julien.meddah@deveryware.com>
|
||||
Michiel Sikma <michiel@wedemandhtml.com>
|
||||
Jakob Krigovsky <jakob.krigovsky@gmail.com>
|
||||
Charmander <~@charmander.me>
|
||||
Erik Wienhold <git@ewie.name>
|
||||
James Butler <james.butler@sandfox.co.uk>
|
||||
Kevin Kragenbrink <kevin@gaikai.com>
|
||||
Arnaud Rinquin <rinquin.arnaud@gmail.com>
|
||||
Mike MacCana <mike.maccana@gmail.com>
|
||||
Antti Mattila <anttti@fastmail.fm>
|
||||
laiso <laiso@lai.so>
|
||||
Matt Zorn <zornme@gmail.com>
|
||||
Kyle Mitchell <kyle@kemitchell.com>
|
||||
Jeremiah Senkpiel <fishrock123@rocketmail.com>
|
||||
Michael Klein <mischkl@users.noreply.github.com>
|
||||
Simen Bekkhus <sbekkhus91@gmail.com>
|
||||
Victor <victor.shih@gmail.com>
|
||||
thefourtheye <thechargingvolcano@gmail.com>
|
||||
Clay Carpenter <claycarpenter@gmail.com>
|
||||
bangbang93 <bangbang93@163.com>
|
||||
Nick Malaguti <nmalaguti@palantir.com>
|
||||
Cedric Nelson <cedric.nelson@gmail.com>
|
||||
Kat Marchán <kzm@zkat.tech>
|
||||
Andrew <talktome@aboutandrew.co.uk>
|
||||
Eduardo Pinho <enet4mikeenet@gmail.com>
|
||||
Rachel Hutchison <rhutchix@intel.com>
|
||||
Ryan Temple <ryantemple145@gmail.com>
|
||||
Eugene Sharygin <eush77@gmail.com>
|
||||
James Talmage <james@talmage.io>
|
||||
jane arc <jane@uber.com>
|
||||
Joseph Dykstra <josephdykstra@gmail.com>
|
||||
Andrew Crites <ajcrites@gmail.com>
|
||||
Joshua Egan <josh-egan@users.noreply.github.com>
|
||||
Carlos Alberto <euprogramador@gmail.com>
|
||||
Thomas Cort <thomasc@ssimicro.com>
|
||||
Thaddee Tyl <thaddee.tyl@gmail.com>
|
||||
Steve Klabnik <steve@steveklabnik.com>
|
||||
Andrew Murray <radarhere@gmail.com>
|
||||
Stephan Bönnemann <stephan@excellenteasy.com>
|
||||
Kyle M. Tarplee <kyle.tarplee@numerica.us>
|
||||
Derek Peterson <derekpetey@gmail.com>
|
||||
Greg Whiteley <greg.whiteley@atomos.com>
|
||||
murgatroid99 <mlumish@google.com>
|
||||
Marcin Cieslak <saper@saper.info>
|
||||
João Reis <reis@janeasystems.com>
|
||||
Matthew Hasbach <hasbach.git@gmail.com>
|
||||
Jon Hall <jon_hall@outlook.com>
|
||||
Anna Henningsen <sqrt@entless.org>
|
||||
James Treworgy <jamietre@gmail.com>
|
||||
James Hartig <james@levenlabs.com>
|
||||
Stephanie Snopek <stephaniesnopek@gmail.com>
|
||||
Kent C. Dodds <kent@doddsfamily.us>
|
||||
Aaron Krause <aaronjkrause@gmail.com>
|
||||
Daniel K O'Leary <daniel@dko.io>
|
||||
fscherwi <fscherwi@users.noreply.github.com>
|
||||
Thomas Reggi <thomas@reggi.com>
|
||||
Thomas Michael McTiernan <thomasmctiernan@gmail.com>
|
||||
Jason Kurian <JaKXz@users.noreply.github.com>
|
||||
Sebastiaan Deckers <seb@ninja.sg>
|
||||
lady3bean <lady3bean@users.noreply.github.com>
|
||||
Tomi Carr <TaMe3971@users.noreply.github.com>
|
||||
Juan Caicedo <retiredcanadianpoet@gmail.com>
|
||||
Ashley Williams <ashley@npmjs.com>
|
||||
Andrew Marcinkevičius <andrew.web@ifdattic.com>
|
||||
Jorrit Schippers <jorrit@ncode.nl>
|
||||
Alex Lukin <alex.lukin@softgrad.com>
|
||||
Aria Stewart <aredridel@dinhe.net>
|
||||
Tiago Rodrigues <tmcrodrigues@gmail.com>
|
||||
Tim <tim-github@baverstock.org.uk>
|
||||
Nick Williams <WickyNilliams@users.noreply.github.com>
|
||||
Louis Larry <louis.larry@gmail.com>
|
||||
Ben Gotow <bengotow@gmail.com>
|
||||
Jakub Gieryluk <jakub.g.opensource@gmail.com>
|
||||
Kevin Lorenz <mail@kevinlorenz.com>
|
||||
Martin von Gagern <Martin.vGagern@gmx.net>
|
||||
Eymen Gunay <eymen@egunay.com>
|
||||
Martin Ek <mail@ekmartin.com>
|
||||
Rafał Pocztarski <r.pocztarski@gmail.com>
|
||||
Mark Reeder <mreeder@uber.com>
|
||||
Chris Rebert <github@chrisrebert.com>
|
||||
Scott Addie <tobias.addie@gmail.com>
|
||||
Jeff McMahan <jeffrey.lee.mcmahan@gmail.com>
|
||||
Tim Krins <timkrins@gmail.com>
|
||||
Hal Henke <halhenke@gmail.com>
|
||||
Julian Simioni <julian@simioni.org>
|
||||
Jimb Esser <jimb@yahoo-inc.com>
|
||||
Alexis Campailla <alexis@janeasystems.com>
|
||||
Chris Chua <chris.sirhc@gmail.com>
|
||||
Beau Gunderson <beau@beaugunderson.com>
|
||||
Dave Galbraith <dave@jut.io>
|
||||
s100 <shughes1@uk.ibm.com>
|
||||
Sergey Simonchik <sergey.simonchik@jetbrains.com>
|
||||
Vanja Radovanović <elvanja@gmail.com>
|
||||
Jonathan Persson <persson.jonathan@gmail.com>
|
||||
Vedat Mahir YILMAZ <mahir@vedatmahir.com>
|
||||
Samuel Reed <samuel.trace.reed@gmail.com>
|
||||
Rafał Legiędź <rafal.legiedz@gmail.com>
|
||||
Jan Schär <jscissr@gmail.com>
|
||||
Xcat Liu <xcatliu@gmail.com>
|
||||
harryh <Aourin@users.noreply.github.com>
|
||||
Prayag Verma <prayag.verma@gmail.com>
|
||||
Neil Kistner <neil.kistner@gmail.com>
|
||||
Zoujie Wzj <zoujie.wzj@alibaba-inc.com>
|
||||
Ryan Hendrickson <ryan.hendrickson@alum.mit.edu>
|
||||
Arturo Coronel <aoitsu3@gmail.com>
|
||||
Hutson Betts <hbetts@factset.com>
|
||||
Lewis Cowper <lewis.cowper@googlemail.com>
|
||||
Adam Byrne <misterbyrne@gmail.com>
|
||||
Ifeanyi Oraelosi <ifeanyioraelosi@gmail.com>
|
||||
Robert Ludwig <rob.ludwig@rideamigos.com>
|
||||
Chris Warren <chris@ixalon.net>
|
||||
Scott Plumlee <scott@plumlee.org>
|
||||
Daniel Pedersen <daniel@scandinav.se>
|
||||
rhgb <kaiserdaemon@gmail.com>
|
||||
doug.wade <doug.wade@redfin.com>
|
||||
Zac <zdoege@gm.slc.edu>
|
||||
GriffinSchneider <griffinschneider@gmail.com>
|
||||
Andres Kalle <mjomble@gmail.com>
|
||||
thefourtheye <thefourtheye@users.noreply.github.com>
|
||||
Yael <yaelz@users.noreply.github.com>
|
||||
Yann Odeyer <yann@odeyer.com>
|
||||
James Monger <jameskmonger@hotmail.co.uk>
|
||||
Thomas Hallock <thomas@1stdibs.com>
|
||||
Paul Irish <paul.irish@gmail.com>
|
||||
Paul O'Leary McCann <polm@dampfkraft.com>
|
||||
Francis Gulotta <wizard@roborooter.com>
|
||||
Felix Rieseberg <felix@felixrieseberg.com>
|
||||
Glen Mailer <glenjamin@gmail.com>
|
||||
Federico Brigante <bfred-it@users.noreply.github.com>
|
||||
Steve Mao <maochenyan@gmail.com>
|
||||
Anna Henningsen <anna@addaleax.net>
|
||||
Rachel Evans <git@rve.org.uk>
|
||||
Sam Minnee <sam@silverstripe.com>
|
||||
Zirak <zirakertan@gmail.com>
|
||||
Daniel Lupu <lupu.daniel.f@gmail.com>
|
||||
Gianluca Casati <fibo@users.noreply.github.com>
|
||||
André Herculano <andresilveirah@gmail.com>
|
||||
Wyatt Preul <wpreul@gmail.com>
|
||||
Myles Borins <mborins@us.ibm.com>
|
||||
Elliot Lee <github.public@intelliot.com>
|
||||
Dmitry Kirilyuk <gk.joker@gmail.com>
|
||||
Aaron Tribou <aaron.tribou@gmail.com>
|
||||
Tapani Moilanen <moilanen.tapani@gmail.com>
|
||||
Han Seoul-Oh <laughinghan@gmail.com>
|
||||
Aleksey Shvayka <shvaikalesh@gmail.com>
|
||||
Emma Ramirez <ramirez.emma.g@gmail.com>
|
||||
Julian Duque <julianduquej@gmail.com>
|
||||
Simon MacDonald <simon.macdonald@gmail.com>
|
||||
Adam Stankiewicz <sheerun@sher.pl>
|
||||
Gregers Gram Rygg <gregers.gram.rygg@finn.no>
|
||||
Peter Dave Hello <hsu@peterdavehello.org>
|
||||
Jordan Klassen <forivall@gmail.com>
|
||||
Jason Palmer <jason@jason-palmer.com>
|
||||
Michael Hart <michael.hart.au@gmail.com>
|
||||
Sasha Koss <koss@nocorp.me>
|
||||
David Emmerson <david.emmerson@gmail.com>
|
||||
Christophe Hurpeau <christophe@hurpeau.com>
|
||||
Daniel Paz-Soldan <daniel.pazsoldan@gmail.com>
|
||||
Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
|
||||
Zach Renner <zarenner@microsoft.com>
|
||||
Christopher Hiller <boneskull@boneskull.com>
|
||||
Joshua Bennett <legodudejb@gmail.com>
|
||||
Andrew Meyer <andrewm.bpi@gmail.com>
|
||||
Michael Jasper <mdjasper@gmail.com>
|
||||
Max <contact@mstoiber.com>
|
||||
Szymon Nowak <szimek@gmail.com>
|
||||
Jason Karns <jason.karns@gmail.com>
|
||||
Lucas Holmquist <lholmqui@redhat.com>
|
||||
Ionică Bizău <bizauionica@gmail.com>
|
||||
Alex Chesters <AlexChesters@users.noreply.github.com>
|
||||
Robert Gay <robert.gay@redfin.com>
|
||||
Steven <stevokk@hotmail.com>
|
||||
Tim Caswell <tim@creationix.com>
|
||||
Anna Henningsen <github@addaleax.net>
|
||||
Kim Røen <kim@kimroen.com>
|
||||
Douglas Wilson <dougwilson@live.com>
|
||||
Mike Engel <mike@mike-engel.com>
|
||||
baderbuddy <baderbuddy@gmail.com>
|
||||
Alex Jordan <alex@strugee.net>
|
||||
Ville Lahdenvuo <tuhoojabotti@gmail.com>
|
||||
Natalie Wolfe <nwolfe@newrelic.com>
|
||||
Andrew Schmadel <aschmadel@learningobjects.com>
|
||||
Jonah Moses <jonahkmoses@gmail.com>
|
||||
Daijirō Wachi <daijiro.wachi@gmail.com>
|
||||
Dmitry Litvinchenko <karaliti@gmail.com>
|
||||
chocolateboy <chocolate@cpan.org>
|
||||
Henry Zhu <hi@henryzoo.com>
|
||||
Nate Goldman <ungoldman@gmail.com>
|
||||
Ted Yavuzkurt <hello@TedY.io>
|
||||
Arseniy Maximov <localhost@kern0.ru>
|
||||
Evgeny Kulikov <beyondcompute@users.noreply.github.com>
|
||||
Сковорода Никита Андреевич <chalkerx@gmail.com>
|
||||
Carol (Nichols || Goulding) <carol.nichols@gmail.com>
|
||||
Jarid Margolin <jaridmargolin@gmail.com>
|
||||
David Cook <divergentdave@gmail.com>
|
||||
Brian Dukes <bdukes@engagesoftware.com>
|
||||
Jed Fox <git@twopointzero.us>
|
||||
Pavlo Liulia <pavloblack@hotmail.com>
|
||||
Ján Dzurek <famousgarkin@outlook.com>
|
||||
Lucas Theisen <ltheisen@mitre.org>
|
||||
Mike Sherov <mike.sherov@gmail.com>
|
||||
薛定谔的猫 <hh_2013@foxmail.com>
|
||||
Paweł Lula <pavloblack@hotmail.com>
|
||||
Jakob Krigovsky <jakob@krigovsky.com>
|
||||
George Rawlinson <george@rawlinson.net.nz>
|
||||
Jack Nagel <jacknagel@users.noreply.github.com>
|
||||
Andreas Kohn <andreas.kohn@gmail.com>
|
||||
Jason Wohlgemuth <jhwohlgemuth@users.noreply.github.com>
|
||||
Ryan Graham <r.m.graham@gmail.com>
|
||||
Hirse <jan.pilzer@gmx.de>
|
||||
Colin Rotherham <work@colinr.com>
|
||||
Aki <hi@akiro.se>
|
||||
Emily Marigold Klassen <forivall@gmail.com>
|
||||
Ramana Venkata <idlike2dream@gmail.com>
|
||||
kierendixon <knitesoulja@hotmail.com>
|
||||
Rácz Tibor Zoltán <racztiborzoltan@gmail.com>
|
||||
Guangcong Luo <guangcongluo@gmail.com>
|
||||
Steven <steven@ceriously.com>
|
||||
Jan Pilzer <jan.pilzer@gmx.de>
|
||||
Leonard Martin <leonard.martin@gmail.com>
|
||||
Teddy Katz <teddy.katz@gmail.com>
|
||||
Simon Legg <leggsimon@gmail.com>
|
||||
Kin Lum <kenneth.kin.lum@gmail.com>
|
||||
David Rousselie <guido.dassori@gmail.com>
|
||||
Jože Mlakar <JozeM@ixtlan-team.si>
|
||||
happylynx <happylynx@users.noreply.github.com>
|
||||
Dominic Watson <intellix@users.noreply.github.com>
|
||||
Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
|
||||
Brian Beck <exogen@gmail.com>
|
||||
Ramana Venkata <vramana@users.noreply.github.com>
|
||||
Misha Kaletsky <misha.kaletsky@gmail.com>
|
||||
Andrew Schmadel <schmod@users.noreply.github.com>
|
||||
AJ Jordan <alex@strugee.net>
|
||||
Mark Banner <standard8@mozilla.com>
|
||||
Richard Simko <richardsimko@users.noreply.github.com>
|
||||
Sanketh Katta <sankethkatta@gmail.com>
|
||||
Tim Needham <tim.needham@wmfs.net>
|
||||
Leonardo Rojas <leonardo.rojas@shopify.com>
|
||||
Mark Peter Fejes <fejes.mark@gmail.com>
|
||||
Ryan Florence <rpflorence@gmail.com>
|
||||
MichaelQQ <mingsian.tu@vpon.com>
|
||||
Anders D. Johnson <anders.d.johnson.developer@gmail.com>
|
||||
Benjamin Fernandes <lotharsee@gmail.com>
|
||||
Simon Kurtz <simonkurtz@gmail.com>
|
||||
David Goss <david@davidgoss.co.uk>
|
||||
Luis Gustavo Pereira <lgp1985@yahoo.com.br>
|
||||
Amos Wenger <fasterthanlime@users.noreply.github.com>
|
||||
Samuel Marks <samuelmarks@gmail.com>
|
||||
Victor Travieso <victor@grabcad.com>
|
||||
Joshua Chaitin-Pollak <jbcpollak@users.noreply.github.com>
|
||||
Brendan Warkentin <faazshift@gmail.com>
|
||||
Scott Santucci <ScottFreeCode@users.noreply.github.com>
|
||||
Xavier Cambar <xcambar@gmail.com>
|
||||
Vikram <nrvikram19@gmail.com>
|
||||
Igor Nadj <igor.nadj@shinesolutions.com>
|
||||
Tong Li <supertong@users.noreply.github.com>
|
||||
tripu <t@tripu.info>
|
||||
Carsten Brandt <mail@cebe.cc>
|
||||
Marcin Szczepanski <marcin@imagichine.com.au>
|
||||
Josh Clow <josh@textio.com>
|
||||
Jakub Holy <jakubholy@jakubholy.net>
|
||||
Alexandra Ulsh <alexandra.ulsh@gmail.com>
|
||||
Tom MacWright <tmcw@users.noreply.github.com>
|
||||
Felicio Mununga <felicio@users.noreply.github.com>
|
||||
Gabor Szabo <gszabo@users.noreply.github.com>
|
||||
Andreas Müller <mail@devmount.de>
|
||||
Andrew Pitman <apitman@users.noreply.github.com>
|
||||
Jacob Wejendorp <jacob@wejendorp.dk>
|
||||
Alejandro López <a.lopez.sanchez@outlook.es>
|
||||
Victor Belozyorov <hi@vbelozyorov.com>
|
||||
Bradley Farias <bfarias@godaddy.com>
|
||||
Kyle E. Mitchell <kyle@kemitchell.com>
|
||||
Tuan Anh Tran <me@tuananh.org>
|
||||
Nathan Woltman <nwoltman@outlook.com>
|
||||
Kyra <kyranet@users.noreply.github.com>
|
||||
Leаh Neukirchen <chneukirchen@gmail.com>
|
||||
Kyle Spier-Swenson <kyleshome@gmail.com>
|
||||
Joe Bowbeer <joe.bowbeer@gmail.com>
|
||||
Nalin Bhardwaj <6984346+nalinbhardwaj@users.noreply.github.com>
|
||||
Nicolas Garnier <ngarnier@users.noreply.github.com>
|
||||
Vladislav Rassokhin <vladrassokhin@gmail.com>
|
||||
Josh Goldberg <joshuakgoldberg@outlook.com>
|
||||
laggingreflex <laggingreflex@gmail.com>
|
||||
Kristofer Selbekk <selbekk@users.noreply.github.com>
|
||||
Sreenivas Alapati <sreenivas9alapati@gmail.com>
|
||||
Ben Creasy <ben@bencreasy.com>
|
||||
Allan Kimmer Jensen <allankimmerjensen@gmail.com>
|
||||
rinfan <rinfan@users.noreply.github.com>
|
||||
Matt Hoyle <code@deployable.co>
|
||||
Mason Pawsey <mpawsey@csub.edu>
|
||||
Johannes Bader <olydis@users.noreply.github.com>
|
||||
Michael Zabka <zabka.michael@gmail.com>
|
||||
Bruce MacNaughton <bmacnaughton@gmail.com>
|
||||
Christopher Patty <christopher.patty@aggiemail.usu.edu>
|
||||
Max Stoiber <contact@mxstbr.com>
|
||||
Enrico Weigelt <enrico.weigelt@gr13.net>
|
||||
David Hu <davidjhu@gmail.com>
|
||||
Steven R. Loomis <srl295@gmail.com>
|
||||
Julien Deniau <julien.deniau@gmail.com>
|
||||
Prasanna Venkatesh T S <vipranarayan14@gmail.com>
|
||||
Alec Larson <aleclarson@users.noreply.github.com>
|
||||
John-David Dalton <john.david.dalton@gmail.com>
|
||||
Raymond Feng <enjoyjava@gmail.com>
|
||||
Tieme van Veen <tiemevanveen@hotmail.com>
|
||||
Finn Pauls <derfinn@gmail.com>
|
||||
Jeremy Kahn <jeremyckahn@gmail.com>
|
||||
Mertcan Mermerkaya <mertcan@mermerkaya.net>
|
||||
Will Yardley <wyardley@users.noreply.github.com>
|
||||
Matt Travi <github@travi.org>
|
||||
Solomon Victorino <solomonvictorino@gmail.com>
|
||||
Rich Trott <rtrott@gmail.com>
|
||||
Maksym Kobieliev <maximaximums@gmail.com>
|
||||
Thomas Reggi <socialtr@gmail.com>
|
||||
David Gilbertson <gilbertson.david@gmail.com>
|
||||
Rob Lourens <roblourens@gmail.com>
|
||||
Karan Thakkar <karanjthakkar@gmail.com>
|
||||
Howard T. Chiam <hchiam@users.noreply.github.com>
|
||||
Geoffrey Mattie <info@geoffreymattie.com>
|
||||
Luis Lobo Borobia <luislobo@gmail.com>
|
||||
Aaron Tribou <tribou@users.noreply.github.com>
|
||||
刘祺 <gucong@gmail.com>
|
||||
Brad Johnson <bradsk88@gmail.com>
|
||||
Artem Varaksa <aymfst@gmail.com>
|
||||
Mary <Ipadlover8322@gmail.com>
|
||||
Darryl Pogue <dvpdiner2@gmail.com>
|
||||
Rick Schubert <rickschubert@gmx.de>
|
||||
Daniel W <dwilches@gmail.com>
|
||||
XhmikosR <xhmikosr@gmail.com>
|
||||
Martin Kühl <mkhl@users.noreply.github.com>
|
||||
Valentin Ouvrard <valentin210594@gmail.com>
|
||||
Noah Benham <noahbenham@users.noreply.github.com>
|
||||
Brian Olore <brian@olore.net>
|
||||
Mat Warger <mwarger@gmail.com>
|
||||
Federico Rampazzo <frampone@gmail.com>
|
||||
SneakyFish5 <32284796+SneakyFish5@users.noreply.github.com>
|
||||
Nikki Everett <neverett@users.noreply.github.com>
|
||||
Erik Price <github@erikprice.net>
|
||||
Lars Willighagen <lars.willighagen@gmail.com>
|
||||
Kevin Gibbons <bakkot@gmail.com>
|
||||
Maarten Balliauw <maarten@balliauw.be>
|
||||
Mehdy Dara <mdara@eleven-labs.com>
|
||||
Robert Kielty <rob.kielty@gmail.com>
|
||||
Scott Trinh <scottyparade@gmail.com>
|
||||
Hugo <hugovk@users.noreply.github.com>
|
||||
Jacob <jakeincanada@icloud.com>
|
||||
Joe Bottigliero <joe@bottigliero.com>
|
||||
Nikolai Vavilov <vvnicholas@gmail.com>
|
||||
Kelvin Jin <kelvinjin@google.com>
|
||||
乱序 <midare@utakana.de>
|
||||
1328
website/node_modules/npm/CHANGELOG.md
generated
vendored
Normal file
1328
website/node_modules/npm/CHANGELOG.md
generated
vendored
Normal file
File diff suppressed because it is too large
Load Diff
82
website/node_modules/npm/CONTRIBUTING.md
generated
vendored
Normal file
82
website/node_modules/npm/CONTRIBUTING.md
generated
vendored
Normal file
@@ -0,0 +1,82 @@
|
||||
# npm CLI Contributor Roles and Responsibilities
|
||||
|
||||
## Table of Contents
|
||||
|
||||
* [Introduction](#introduction)
|
||||
* [Roles](#roles)
|
||||
* [Community Members](#community-members)
|
||||
* [Collaborators](#collaborators)
|
||||
* [npm, Inc Employees](#npm-inc-employees)
|
||||
|
||||
|
||||
## Introduction
|
||||
|
||||
Welcome to the npm CLI Contributor Guide! This document outlines the npm CLI repository's process for community interaction and contribution. This includes the issue tracker, pull requests, wiki pages, and, to a certain extent, outside communication in the context of the npm CLI. It defines roles, responsibilities, and procedures, and is an entry point for anyone wishing to contribute their time and effort to making npm a better tool for the JavaScript community!
|
||||
|
||||
All interactions in the npm repository are covered by the [npm Code of Conduct](https://www.npmjs.com/policies/conduct)
|
||||
|
||||
## Roles
|
||||
|
||||
There are three main roles for people participating in the npm issue tracker. Each has a specific set of abilities and responsibilities: [Community members](#community-members), [Collaborators](#collaborators), and [npm, Inc employees](#npm-inc-employees).
|
||||
|
||||
Failure to comply with the expected responsibilities of each role, or violating the Code of Conduct will result in punitive action relative to the transgression, ranging from a warning to full removal from the project, at the discretion of npm employees.
|
||||
|
||||
### Community Members
|
||||
|
||||
This includes anyone who may show up to the npm/npm repo with issues, PRs, comments etc. They may not have any other involvement with npm.
|
||||
|
||||
#### Abilities
|
||||
|
||||
* Open issues and PRs
|
||||
* Comment on issues and PRs
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
* Comment on issues when they have a reference to the answer.
|
||||
* If community members aren't sure they are correct and don't have a reference to the answer, please leave the issue and try another one.
|
||||
* Defer to collaborators and npm employees for answers.
|
||||
* Make sure to search for [the troubleshooting posts on npm.community](https://npm.community/c/support/troubleshooting) and search on the issue tracker for similar issues before opening a new one.
|
||||
* Any users with urgent support needs are welcome to email support@npmjs.com, and our dedicated support team will be happy to help.
|
||||
|
||||
PLEASE don't @ collaborators or npm employees on issues. The CLI team is small, and has many outstanding commitments to fulfill.
|
||||
|
||||
### Collaborators
|
||||
|
||||
These are folks who have the ability to label and close issues. The role of collaborators may expand over time, but for now it is a limited (& important) role. This is an excellent way to contribute to npm without writing code.
|
||||
|
||||
Community members may become collaborators by showing consistent, proven track record of quality contributions to the project, a reasonable level of proficiency with the CLI, and regular participation through the tracker and other related mediums, including regular contact with the CLI team itself. This role entails a higher level of responsibility than community member, so we ask for a higher level of understanding and commitment.
|
||||
|
||||
Collaborators who become inactive for 3 months or longer may have their collaborator privileges removed until they are ready to return.
|
||||
|
||||
#### Abilities
|
||||
|
||||
* Label/triage new issues
|
||||
* Respond to ongoing issues
|
||||
* Close resolved issues.
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
* Only answer questions when they know the answer, and provide a reference to the answer.
|
||||
* If collaborators aren't totally confident about their answer, please leave the issue and try another one.
|
||||
* If they've responded to an issue, it becomes their responsibility to see it to resolution.
|
||||
* Defer to fellow Collaborators & npm employees for answers (Again, please don't @ collaborators or npm employees, thank you!)
|
||||
* Make sure to search [the troubleshooting posts on npm.community](https://npm.community/c/support/troubleshooting) and search the rest of the forum for similar topics.
|
||||
|
||||
### npm, Inc Employees
|
||||
|
||||
Folks who work at npm, Inc, who have a responsibility to ensure the stability and functionality of the tools npm offers.
|
||||
|
||||
#### Abilities
|
||||
|
||||
* Label/triage new issues
|
||||
* Respond to ongoing issues
|
||||
* Close resolved issues
|
||||
* Land PRs
|
||||
|
||||
Please note that this is a living document, and the CLI team will put up PRs to it as needed.
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
* Preserve and promote the health of the CLI, the registry, the website, etc.
|
||||
|
||||
In special cases, [Collaborators](#collaborators) may request time to speak with an npm employee directly, by contacting them and coordinating a time/place.
|
||||
235
website/node_modules/npm/LICENSE
generated
vendored
Normal file
235
website/node_modules/npm/LICENSE
generated
vendored
Normal file
@@ -0,0 +1,235 @@
|
||||
The npm application
|
||||
Copyright (c) npm, Inc. and Contributors
|
||||
Licensed on the terms of The Artistic License 2.0
|
||||
|
||||
Node package dependencies of the npm application
|
||||
Copyright (c) their respective copyright owners
|
||||
Licensed on their respective license terms
|
||||
|
||||
The npm public registry at https://registry.npmjs.org
|
||||
and the npm website at https://www.npmjs.com
|
||||
Operated by npm, Inc.
|
||||
Use governed by terms published on https://www.npmjs.com
|
||||
|
||||
"Node.js"
|
||||
Trademark Joyent, Inc., https://joyent.com
|
||||
Neither npm nor npm, Inc. are affiliated with Joyent, Inc.
|
||||
|
||||
The Node.js application
|
||||
Project of Node Foundation, https://nodejs.org
|
||||
|
||||
The npm Logo
|
||||
Copyright (c) Mathias Pettersson and Brian Hammond
|
||||
|
||||
"Gubblebum Blocky" typeface
|
||||
Copyright (c) Tjarda Koster, https://jelloween.deviantart.com
|
||||
Used with permission
|
||||
|
||||
|
||||
--------
|
||||
|
||||
|
||||
The Artistic License 2.0
|
||||
|
||||
Copyright (c) 2000-2006, The Perl Foundation.
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
This license establishes the terms under which a given free software
|
||||
Package may be copied, modified, distributed, and/or redistributed.
|
||||
The intent is that the Copyright Holder maintains some artistic
|
||||
control over the development of that Package while still keeping the
|
||||
Package available as open source and free software.
|
||||
|
||||
You are always permitted to make arrangements wholly outside of this
|
||||
license directly with the Copyright Holder of a given Package. If the
|
||||
terms of this license do not permit the full use that you propose to
|
||||
make of the Package, you should contact the Copyright Holder and seek
|
||||
a different licensing arrangement.
|
||||
|
||||
Definitions
|
||||
|
||||
"Copyright Holder" means the individual(s) or organization(s)
|
||||
named in the copyright notice for the entire Package.
|
||||
|
||||
"Contributor" means any party that has contributed code or other
|
||||
material to the Package, in accordance with the Copyright Holder's
|
||||
procedures.
|
||||
|
||||
"You" and "your" means any person who would like to copy,
|
||||
distribute, or modify the Package.
|
||||
|
||||
"Package" means the collection of files distributed by the
|
||||
Copyright Holder, and derivatives of that collection and/or of
|
||||
those files. A given Package may consist of either the Standard
|
||||
Version, or a Modified Version.
|
||||
|
||||
"Distribute" means providing a copy of the Package or making it
|
||||
accessible to anyone else, or in the case of a company or
|
||||
organization, to others outside of your company or organization.
|
||||
|
||||
"Distributor Fee" means any fee that you charge for Distributing
|
||||
this Package or providing support for this Package to another
|
||||
party. It does not mean licensing fees.
|
||||
|
||||
"Standard Version" refers to the Package if it has not been
|
||||
modified, or has been modified only in ways explicitly requested
|
||||
by the Copyright Holder.
|
||||
|
||||
"Modified Version" means the Package, if it has been changed, and
|
||||
such changes were not explicitly requested by the Copyright
|
||||
Holder.
|
||||
|
||||
"Original License" means this Artistic License as Distributed with
|
||||
the Standard Version of the Package, in its current version or as
|
||||
it may be modified by The Perl Foundation in the future.
|
||||
|
||||
"Source" form means the source code, documentation source, and
|
||||
configuration files for the Package.
|
||||
|
||||
"Compiled" form means the compiled bytecode, object code, binary,
|
||||
or any other form resulting from mechanical transformation or
|
||||
translation of the Source form.
|
||||
|
||||
|
||||
Permission for Use and Modification Without Distribution
|
||||
|
||||
(1) You are permitted to use the Standard Version and create and use
|
||||
Modified Versions for any purpose without restriction, provided that
|
||||
you do not Distribute the Modified Version.
|
||||
|
||||
|
||||
Permissions for Redistribution of the Standard Version
|
||||
|
||||
(2) You may Distribute verbatim copies of the Source form of the
|
||||
Standard Version of this Package in any medium without restriction,
|
||||
either gratis or for a Distributor Fee, provided that you duplicate
|
||||
all of the original copyright notices and associated disclaimers. At
|
||||
your discretion, such verbatim copies may or may not include a
|
||||
Compiled form of the Package.
|
||||
|
||||
(3) You may apply any bug fixes, portability changes, and other
|
||||
modifications made available from the Copyright Holder. The resulting
|
||||
Package will still be considered the Standard Version, and as such
|
||||
will be subject to the Original License.
|
||||
|
||||
|
||||
Distribution of Modified Versions of the Package as Source
|
||||
|
||||
(4) You may Distribute your Modified Version as Source (either gratis
|
||||
or for a Distributor Fee, and with or without a Compiled form of the
|
||||
Modified Version) provided that you clearly document how it differs
|
||||
from the Standard Version, including, but not limited to, documenting
|
||||
any non-standard features, executables, or modules, and provided that
|
||||
you do at least ONE of the following:
|
||||
|
||||
(a) make the Modified Version available to the Copyright Holder
|
||||
of the Standard Version, under the Original License, so that the
|
||||
Copyright Holder may include your modifications in the Standard
|
||||
Version.
|
||||
|
||||
(b) ensure that installation of your Modified Version does not
|
||||
prevent the user installing or running the Standard Version. In
|
||||
addition, the Modified Version must bear a name that is different
|
||||
from the name of the Standard Version.
|
||||
|
||||
(c) allow anyone who receives a copy of the Modified Version to
|
||||
make the Source form of the Modified Version available to others
|
||||
under
|
||||
|
||||
(i) the Original License or
|
||||
|
||||
(ii) a license that permits the licensee to freely copy,
|
||||
modify and redistribute the Modified Version using the same
|
||||
licensing terms that apply to the copy that the licensee
|
||||
received, and requires that the Source form of the Modified
|
||||
Version, and of any works derived from it, be made freely
|
||||
available in that license fees are prohibited but Distributor
|
||||
Fees are allowed.
|
||||
|
||||
|
||||
Distribution of Compiled Forms of the Standard Version
|
||||
or Modified Versions without the Source
|
||||
|
||||
(5) You may Distribute Compiled forms of the Standard Version without
|
||||
the Source, provided that you include complete instructions on how to
|
||||
get the Source of the Standard Version. Such instructions must be
|
||||
valid at the time of your distribution. If these instructions, at any
|
||||
time while you are carrying out such distribution, become invalid, you
|
||||
must provide new instructions on demand or cease further distribution.
|
||||
If you provide valid instructions or cease distribution within thirty
|
||||
days after you become aware that the instructions are invalid, then
|
||||
you do not forfeit any of your rights under this license.
|
||||
|
||||
(6) You may Distribute a Modified Version in Compiled form without
|
||||
the Source, provided that you comply with Section 4 with respect to
|
||||
the Source of the Modified Version.
|
||||
|
||||
|
||||
Aggregating or Linking the Package
|
||||
|
||||
(7) You may aggregate the Package (either the Standard Version or
|
||||
Modified Version) with other packages and Distribute the resulting
|
||||
aggregation provided that you do not charge a licensing fee for the
|
||||
Package. Distributor Fees are permitted, and licensing fees for other
|
||||
components in the aggregation are permitted. The terms of this license
|
||||
apply to the use and Distribution of the Standard or Modified Versions
|
||||
as included in the aggregation.
|
||||
|
||||
(8) You are permitted to link Modified and Standard Versions with
|
||||
other works, to embed the Package in a larger work of your own, or to
|
||||
build stand-alone binary or bytecode versions of applications that
|
||||
include the Package, and Distribute the result without restriction,
|
||||
provided the result does not expose a direct interface to the Package.
|
||||
|
||||
|
||||
Items That are Not Considered Part of a Modified Version
|
||||
|
||||
(9) Works (including, but not limited to, modules and scripts) that
|
||||
merely extend or make use of the Package, do not, by themselves, cause
|
||||
the Package to be a Modified Version. In addition, such works are not
|
||||
considered parts of the Package itself, and are not subject to the
|
||||
terms of this license.
|
||||
|
||||
|
||||
General Provisions
|
||||
|
||||
(10) Any use, modification, and distribution of the Standard or
|
||||
Modified Versions is governed by this Artistic License. By using,
|
||||
modifying or distributing the Package, you accept this license. Do not
|
||||
use, modify, or distribute the Package, if you do not accept this
|
||||
license.
|
||||
|
||||
(11) If your Modified Version has been derived from a Modified
|
||||
Version made by someone other than you, you are nevertheless required
|
||||
to ensure that your Modified Version complies with the requirements of
|
||||
this license.
|
||||
|
||||
(12) This license does not grant you the right to use any trademark,
|
||||
service mark, tradename, or logo of the Copyright Holder.
|
||||
|
||||
(13) This license includes the non-exclusive, worldwide,
|
||||
free-of-charge patent license to make, have made, use, offer to sell,
|
||||
sell, import and otherwise transfer the Package with respect to any
|
||||
patent claims licensable by the Copyright Holder that are necessarily
|
||||
infringed by the Package. If you institute patent litigation
|
||||
(including a cross-claim or counterclaim) against any party alleging
|
||||
that the Package constitutes direct or contributory patent
|
||||
infringement, then this Artistic License to you shall terminate on the
|
||||
date that such litigation is filed.
|
||||
|
||||
(14) Disclaimer of Warranty:
|
||||
THE PACKAGE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS
|
||||
IS' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. THE IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
|
||||
NON-INFRINGEMENT ARE DISCLAIMED TO THE EXTENT PERMITTED BY YOUR LOCAL
|
||||
LAW. UNLESS REQUIRED BY LAW, NO COPYRIGHT HOLDER OR CONTRIBUTOR WILL
|
||||
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
|
||||
DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THE PACKAGE, EVEN IF
|
||||
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
|
||||
--------
|
||||
190
website/node_modules/npm/Makefile
generated
vendored
Normal file
190
website/node_modules/npm/Makefile
generated
vendored
Normal file
@@ -0,0 +1,190 @@
|
||||
# vim: set softtabstop=2 shiftwidth=2:
|
||||
SHELL = bash
|
||||
|
||||
PUBLISHTAG = $(shell node scripts/publish-tag.js)
|
||||
BRANCH = $(shell git rev-parse --abbrev-ref HEAD)
|
||||
|
||||
markdowns = $(shell find doc -name '*.md' | grep -v 'index') README.md
|
||||
|
||||
html_docdeps = html/dochead.html \
|
||||
html/docfoot.html \
|
||||
scripts/doc-build.sh \
|
||||
package.json
|
||||
|
||||
cli_mandocs = $(shell find doc/cli -name '*.md' \
|
||||
|sed 's|.md|.1|g' \
|
||||
|sed 's|doc/cli/|man/man1/|g' ) \
|
||||
man/man1/npm-README.1 \
|
||||
man/man1/npx.1
|
||||
|
||||
files_mandocs = $(shell find doc/files -name '*.md' \
|
||||
|sed 's|.md|.5|g' \
|
||||
|sed 's|doc/files/|man/man5/|g' ) \
|
||||
man/man5/npm-json.5 \
|
||||
man/man5/npm-global.5
|
||||
|
||||
misc_mandocs = $(shell find doc/misc -name '*.md' \
|
||||
|sed 's|.md|.7|g' \
|
||||
|sed 's|doc/misc/|man/man7/|g' ) \
|
||||
man/man7/npm-index.7
|
||||
|
||||
cli_htmldocs = $(shell find doc/cli -name '*.md' \
|
||||
|sed 's|.md|.html|g' \
|
||||
|sed 's|doc/cli/|html/doc/cli/|g' ) \
|
||||
html/doc/README.html
|
||||
|
||||
files_htmldocs = $(shell find doc/files -name '*.md' \
|
||||
|sed 's|.md|.html|g' \
|
||||
|sed 's|doc/files/|html/doc/files/|g' ) \
|
||||
html/doc/files/npm-json.html \
|
||||
html/doc/files/npm-global.html
|
||||
|
||||
misc_htmldocs = $(shell find doc/misc -name '*.md' \
|
||||
|sed 's|.md|.html|g' \
|
||||
|sed 's|doc/misc/|html/doc/misc/|g' ) \
|
||||
html/doc/index.html
|
||||
|
||||
mandocs = $(cli_mandocs) $(files_mandocs) $(misc_mandocs)
|
||||
|
||||
htmldocs = $(cli_htmldocs) $(files_htmldocs) $(misc_htmldocs)
|
||||
|
||||
all: doc
|
||||
|
||||
latest:
|
||||
@echo "Installing latest published npm"
|
||||
@echo "Use 'make install' or 'make link' to install the code"
|
||||
@echo "in this folder that you're looking at right now."
|
||||
node bin/npm-cli.js install -g -f npm ${NPMOPTS}
|
||||
|
||||
install: all
|
||||
node bin/npm-cli.js install -g -f ${NPMOPTS} $(shell node bin/npm-cli.js pack | tail -1)
|
||||
|
||||
# backwards compat
|
||||
dev: install
|
||||
|
||||
link: uninstall
|
||||
node bin/npm-cli.js link -f
|
||||
|
||||
clean: markedclean marked-manclean doc-clean
|
||||
rm -rf npmrc
|
||||
node bin/npm-cli.js cache clean --force
|
||||
|
||||
uninstall:
|
||||
node bin/npm-cli.js rm npm -g -f
|
||||
|
||||
doc: $(mandocs) $(htmldocs)
|
||||
|
||||
markedclean:
|
||||
rm -rf node_modules/marked node_modules/.bin/marked .building_marked
|
||||
|
||||
marked-manclean:
|
||||
rm -rf node_modules/marked-man node_modules/.bin/marked-man .building_marked-man
|
||||
|
||||
docclean: doc-clean
|
||||
doc-clean:
|
||||
rm -rf \
|
||||
.building_marked \
|
||||
.building_marked-man \
|
||||
html/doc \
|
||||
man
|
||||
|
||||
## build-time tools for the documentation
|
||||
build-doc-tools := node_modules/.bin/marked \
|
||||
node_modules/.bin/marked-man
|
||||
|
||||
# use `npm install marked-man` for this to work.
|
||||
man/man1/npm-README.1: README.md scripts/doc-build.sh package.json $(build-doc-tools)
|
||||
@[ -d man/man1 ] || mkdir -p man/man1
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
man/man1/%.1: doc/cli/%.md scripts/doc-build.sh package.json $(build-doc-tools)
|
||||
@[ -d man/man1 ] || mkdir -p man/man1
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
man/man1/npx.1: node_modules/libnpx/libnpx.1
|
||||
cat $< | sed s/libnpx/npx/ > $@
|
||||
|
||||
man/man5/npm-json.5: man/man5/package.json.5
|
||||
cp $< $@
|
||||
|
||||
man/man5/npm-global.5: man/man5/npm-folders.5
|
||||
cp $< $@
|
||||
|
||||
man/man5/%.5: doc/files/%.md scripts/doc-build.sh package.json $(build-doc-tools)
|
||||
@[ -d man/man5 ] || mkdir -p man/man5
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
doc/misc/npm-index.md: scripts/index-build.js package.json $(build-doc-tools)
|
||||
node scripts/index-build.js > $@
|
||||
|
||||
html/doc/index.html: doc/misc/npm-index.md $(html_docdeps) $(build-doc-tools)
|
||||
@[ -d html/doc ] || mkdir -p html/doc
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
man/man7/%.7: doc/misc/%.md scripts/doc-build.sh package.json $(build-doc-tools)
|
||||
@[ -d man/man7 ] || mkdir -p man/man7
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
html/doc/README.html: README.md $(html_docdeps) $(build-doc-tools)
|
||||
@[ -d html/doc ] || mkdir -p html/doc
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
html/doc/cli/%.html: doc/cli/%.md $(html_docdeps) $(build-doc-tools)
|
||||
@[ -d html/doc/cli ] || mkdir -p html/doc/cli
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
html/doc/files/npm-json.html: html/doc/files/package.json.html
|
||||
cp $< $@
|
||||
|
||||
html/doc/files/npm-global.html: html/doc/files/npm-folders.html
|
||||
cp $< $@
|
||||
|
||||
html/doc/files/%.html: doc/files/%.md $(html_docdeps) $(build-doc-tools)
|
||||
@[ -d html/doc/files ] || mkdir -p html/doc/files
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
html/doc/misc/%.html: doc/misc/%.md $(html_docdeps) $(build-doc-tools)
|
||||
@[ -d html/doc/misc ] || mkdir -p html/doc/misc
|
||||
scripts/doc-build.sh $< $@
|
||||
|
||||
|
||||
marked: node_modules/.bin/marked
|
||||
|
||||
node_modules/.bin/marked:
|
||||
node bin/npm-cli.js install marked --no-global --no-timing --no-save
|
||||
|
||||
marked-man: node_modules/.bin/marked-man
|
||||
|
||||
node_modules/.bin/marked-man:
|
||||
node bin/npm-cli.js install marked-man --no-global --no-timing --no-save
|
||||
|
||||
doc: man
|
||||
|
||||
man: $(cli_docs)
|
||||
|
||||
test: doc
|
||||
node bin/npm-cli.js test
|
||||
|
||||
tag:
|
||||
node bin/npm-cli.js tag npm@$(PUBLISHTAG) latest
|
||||
|
||||
ls-ok:
|
||||
node . ls >/dev/null
|
||||
|
||||
gitclean:
|
||||
git clean -fd
|
||||
|
||||
publish: gitclean ls-ok link doc-clean doc
|
||||
@git push origin :v$(shell node bin/npm-cli.js --no-timing -v) 2>&1 || true
|
||||
git push origin $(BRANCH) &&\
|
||||
git push origin --tags &&\
|
||||
node bin/npm-cli.js publish --tag=$(PUBLISHTAG)
|
||||
|
||||
release: gitclean ls-ok markedclean marked-manclean doc-clean doc
|
||||
node bin/npm-cli.js prune --production --no-save
|
||||
@bash scripts/release.sh
|
||||
|
||||
sandwich:
|
||||
@[ $$(whoami) = "root" ] && (echo "ok"; echo "ham" > sandwich) || (echo "make it yourself" && exit 13)
|
||||
|
||||
.PHONY: all latest install dev link doc clean uninstall test man doc-clean docclean release ls-ok realclean
|
||||
166
website/node_modules/npm/README.md
generated
vendored
Normal file
166
website/node_modules/npm/README.md
generated
vendored
Normal file
@@ -0,0 +1,166 @@
|
||||
npm(1) -- a JavaScript package manager
|
||||
==============================
|
||||
|
||||
[](https://travis-ci.org/npm/cli)
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
This is just enough info to get you up and running.
|
||||
|
||||
Much more info will be available via `npm help` once it's installed.
|
||||
|
||||
## IMPORTANT
|
||||
|
||||
**You need node v6 or higher to run this program.**
|
||||
|
||||
To install an old **and unsupported** version of npm that works on node v5
|
||||
and prior, clone the git repo and dig through the old tags and branches.
|
||||
|
||||
**npm is configured to use npm, Inc.'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://www.npmjs.com/policies/terms>.
|
||||
|
||||
You can configure npm to use any compatible registry you
|
||||
like, and even run your own registry. Check out the [doc on
|
||||
registries](https://docs.npmjs.com/misc/registry).
|
||||
|
||||
## Super Easy Install
|
||||
|
||||
npm is bundled with [node](https://nodejs.org/en/download/).
|
||||
|
||||
### Windows Computers
|
||||
|
||||
[Get the MSI](https://nodejs.org/en/download/). npm is in it.
|
||||
|
||||
### Apple Macintosh Computers
|
||||
|
||||
[Get the pkg](https://nodejs.org/en/download/). npm is in it.
|
||||
|
||||
### Other Sorts of Unices
|
||||
|
||||
Run `make install`. npm will be installed with node.
|
||||
|
||||
If you want a more fancy pants install (a different version, customized
|
||||
paths, etc.) then read on.
|
||||
|
||||
## Fancy Install (Unix)
|
||||
|
||||
There's a pretty robust install script at
|
||||
<https://www.npmjs.com/install.sh>. You can download that and run it.
|
||||
|
||||
Here's an example using curl:
|
||||
|
||||
```sh
|
||||
curl -L https://www.npmjs.com/install.sh | sh
|
||||
```
|
||||
|
||||
### Slightly Fancier
|
||||
|
||||
You can set any npm configuration params with that script:
|
||||
|
||||
```sh
|
||||
npm_config_prefix=/some/path sh install.sh
|
||||
```
|
||||
|
||||
Or, you can run it in uber-debuggery mode:
|
||||
|
||||
```sh
|
||||
npm_debug=1 sh install.sh
|
||||
```
|
||||
|
||||
### Even Fancier
|
||||
|
||||
Get the code with git. Use `make` to build the docs and do other stuff.
|
||||
If you plan on hacking on npm, `make link` is your friend.
|
||||
|
||||
If you've got the npm source code, you can also semi-permanently set
|
||||
arbitrary config keys using the `./configure --key=val ...`, and then
|
||||
run npm commands by doing `node bin/npm-cli.js <command> <args>`. (This is helpful
|
||||
for testing, or running stuff without actually installing npm itself.)
|
||||
|
||||
## Windows Install or Upgrade
|
||||
|
||||
Many improvements for Windows users have been made in npm 3 - you will have a better
|
||||
experience if you run a recent version of npm. To upgrade, either use [Microsoft's
|
||||
upgrade tool](https://github.com/felixrieseberg/npm-windows-upgrade),
|
||||
[download a new version of Node](https://nodejs.org/en/download/),
|
||||
or follow the Windows upgrade instructions in the
|
||||
[Installing/upgrading npm](https://npm.community/t/installing-upgrading-npm/251/2) post.
|
||||
|
||||
If that's not fancy enough for you, then you can fetch the code with
|
||||
git, and mess with it directly.
|
||||
|
||||
## Installing on Cygwin
|
||||
|
||||
No.
|
||||
|
||||
## Uninstalling
|
||||
|
||||
So sad to see you go.
|
||||
|
||||
```sh
|
||||
sudo npm uninstall npm -g
|
||||
```
|
||||
Or, if that fails,
|
||||
|
||||
```sh
|
||||
sudo make uninstall
|
||||
```
|
||||
|
||||
## More Severe Uninstalling
|
||||
|
||||
Usually, the above instructions are sufficient. That will remove
|
||||
npm, but leave behind anything you've installed.
|
||||
|
||||
If you would like to remove all the packages that you have installed,
|
||||
then you can use the `npm ls` command to find them, and then `npm rm` to
|
||||
remove them.
|
||||
|
||||
To remove cruft left behind by npm 0.x, you can use the included
|
||||
`clean-old.sh` script file. You can run it conveniently like this:
|
||||
|
||||
```sh
|
||||
npm explore npm -g -- sh scripts/clean-old.sh
|
||||
```
|
||||
|
||||
npm uses two configuration files, one for per-user configs, and another
|
||||
for global (every-user) configs. You can view them by doing:
|
||||
|
||||
```sh
|
||||
npm config get userconfig # defaults to ~/.npmrc
|
||||
npm config get globalconfig # defaults to /usr/local/etc/npmrc
|
||||
```
|
||||
|
||||
Uninstalling npm does not remove configuration files by default. You
|
||||
must remove them yourself manually if you want them gone. Note that
|
||||
this means that future npm installs will not remember the settings that
|
||||
you have chosen.
|
||||
|
||||
## More Docs
|
||||
|
||||
Check out the [docs](https://docs.npmjs.com/).
|
||||
|
||||
You can use the `npm help` command to read any of them.
|
||||
|
||||
If you're a developer, and you want to use npm to publish your program,
|
||||
you should [read this](https://docs.npmjs.com/misc/developers).
|
||||
|
||||
## BUGS
|
||||
|
||||
When you find issues, please report them:
|
||||
|
||||
* web:
|
||||
<https://npm.community/c/bugs>
|
||||
|
||||
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 find npm people in `#npm` on https://package.community/ or
|
||||
[on Twitter](https://twitter.com/npm_support). Whoever responds will no
|
||||
doubt tell you to put the output in a gist or email.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm(1)
|
||||
* npm-help(1)
|
||||
* npm-index(7)
|
||||
34
website/node_modules/npm/appveyor.yml
generated
vendored
Normal file
34
website/node_modules/npm/appveyor.yml
generated
vendored
Normal file
@@ -0,0 +1,34 @@
|
||||
environment:
|
||||
matrix:
|
||||
# LTS is our most important target
|
||||
- nodejs_version: "6"
|
||||
# previous LTS is next most important
|
||||
- nodejs_version: "4"
|
||||
- nodejs_version: "7"
|
||||
# then master
|
||||
- nodejs_version: "8"
|
||||
COVERALLS_REPO_TOKEN:
|
||||
secure: XdC0aySefK0HLh1GNk6aKrzZPbCfPQLyA4mYtFGEp4DrTuZA/iuCUS0LDqFYO8JQ
|
||||
platform:
|
||||
- x86
|
||||
- x64
|
||||
install:
|
||||
- ps: Install-Product node $env:nodejs_version $env:platform
|
||||
- npm config set spin false
|
||||
- npm rebuild
|
||||
- node . install -g .
|
||||
- set "PATH=%APPDATA%\npm;C:\Program Files\Git\mingw64\libexec;%PATH%"
|
||||
- npm install --loglevel=http
|
||||
test_script:
|
||||
- node --version
|
||||
- npm --version
|
||||
- npm run test -- --reporter=classic
|
||||
notifications:
|
||||
- provider: Slack
|
||||
incoming_webhook:
|
||||
secure: vXiG5AgpqxJsXZ0N0CTYDuVrX6RMjBybZKtOx6IbRxCyjgd+DAx6Z9/0XgYQjuof7QFJY3M/U6HxaREQVYbNVHA+C5N5dNALRbKzAC8QNbA=
|
||||
# GO_FAST
|
||||
matrix:
|
||||
fast_finish: true
|
||||
# we don't need the builds, we just need tests
|
||||
build: off
|
||||
6
website/node_modules/npm/bin/node-gyp-bin/node-gyp
generated
vendored
Normal file
6
website/node_modules/npm/bin/node-gyp-bin/node-gyp
generated
vendored
Normal file
@@ -0,0 +1,6 @@
|
||||
#!/usr/bin/env sh
|
||||
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
|
||||
5
website/node_modules/npm/bin/node-gyp-bin/node-gyp.cmd
generated
vendored
Normal file
5
website/node_modules/npm/bin/node-gyp-bin/node-gyp.cmd
generated
vendored
Normal file
@@ -0,0 +1,5 @@
|
||||
if not defined npm_config_node_gyp (
|
||||
node "%~dp0\..\..\node_modules\node-gyp\bin\node-gyp.js" %*
|
||||
) else (
|
||||
node "%npm_config_node_gyp%" %*
|
||||
)
|
||||
34
website/node_modules/npm/bin/npm
generated
vendored
Normal file
34
website/node_modules/npm/bin/npm
generated
vendored
Normal file
@@ -0,0 +1,34 @@
|
||||
#!/bin/sh
|
||||
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
|
||||
|
||||
basedir=`dirname "$0"`
|
||||
|
||||
case `uname` in
|
||||
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
|
||||
esac
|
||||
|
||||
NODE_EXE="$basedir/node.exe"
|
||||
if ! [ -x "$NODE_EXE" ]; then
|
||||
NODE_EXE=node
|
||||
fi
|
||||
|
||||
NPM_CLI_JS="$basedir/node_modules/npm/bin/npm-cli.js"
|
||||
|
||||
case `uname` in
|
||||
*MINGW*)
|
||||
NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
|
||||
NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
|
||||
if [ -f "$NPM_PREFIX_NPM_CLI_JS" ]; then
|
||||
NPM_CLI_JS="$NPM_PREFIX_NPM_CLI_JS"
|
||||
fi
|
||||
;;
|
||||
*CYGWIN*)
|
||||
NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
|
||||
NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
|
||||
if [ -f "$NPM_PREFIX_NPM_CLI_JS" ]; then
|
||||
NPM_CLI_JS="$NPM_PREFIX_NPM_CLI_JS"
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
"$NODE_EXE" "$NPM_CLI_JS" "$@"
|
||||
153
website/node_modules/npm/bin/npm-cli.js
generated
vendored
Normal file
153
website/node_modules/npm/bin/npm-cli.js
generated
vendored
Normal file
@@ -0,0 +1,153 @@
|
||||
#!/usr/bin/env node
|
||||
;(function () { // wrapper in case we're in module_context mode
|
||||
// windows: running "npm blah" in this folder will invoke WSH, not node.
|
||||
/* global WScript */
|
||||
if (typeof WScript !== 'undefined') {
|
||||
WScript.echo(
|
||||
'npm does not work when run\n' +
|
||||
'with the Windows Scripting Host\n\n' +
|
||||
"'cd' to a different directory,\n" +
|
||||
"or type 'npm.cmd <args>',\n" +
|
||||
"or type 'node npm <args>'."
|
||||
)
|
||||
WScript.quit(1)
|
||||
return
|
||||
}
|
||||
|
||||
process.title = 'npm'
|
||||
|
||||
var unsupported = require('../lib/utils/unsupported.js')
|
||||
unsupported.checkForBrokenNode()
|
||||
|
||||
var log = require('npmlog')
|
||||
log.pause() // will be unpaused when config is loaded.
|
||||
log.info('it worked if it ends with', 'ok')
|
||||
|
||||
unsupported.checkForUnsupportedNode()
|
||||
|
||||
var path = require('path')
|
||||
var npm = require('../lib/npm.js')
|
||||
var npmconf = require('../lib/config/core.js')
|
||||
var errorHandler = require('../lib/utils/error-handler.js')
|
||||
|
||||
var configDefs = npmconf.defs
|
||||
var shorthands = configDefs.shorthands
|
||||
var types = configDefs.types
|
||||
var nopt = require('nopt')
|
||||
|
||||
// if npm is called as "npmg" or "npm_g", then
|
||||
// run in global mode.
|
||||
if (path.basename(process.argv[1]).slice(-1) === 'g') {
|
||||
process.argv.splice(1, 1, 'npm', '-g')
|
||||
}
|
||||
|
||||
log.verbose('cli', process.argv)
|
||||
|
||||
var conf = nopt(types, shorthands)
|
||||
npm.argv = conf.argv.remain
|
||||
if (npm.deref(npm.argv[0])) npm.command = npm.argv.shift()
|
||||
else conf.usage = true
|
||||
|
||||
if (conf.version) {
|
||||
console.log(npm.version)
|
||||
return errorHandler.exit(0)
|
||||
}
|
||||
|
||||
if (conf.versions) {
|
||||
npm.command = 'version'
|
||||
conf.usage = false
|
||||
npm.argv = []
|
||||
}
|
||||
|
||||
log.info('using', 'npm@%s', npm.version)
|
||||
log.info('using', 'node@%s', process.version)
|
||||
|
||||
process.on('uncaughtException', errorHandler)
|
||||
|
||||
if (conf.usage && npm.command !== 'help') {
|
||||
npm.argv.unshift(npm.command)
|
||||
npm.command = 'help'
|
||||
}
|
||||
|
||||
var isGlobalNpmUpdate = conf.global && ['install', 'update'].includes(npm.command) && npm.argv.includes('npm')
|
||||
|
||||
// now actually fire up npm and run the command.
|
||||
// this is how to use npm programmatically:
|
||||
conf._exit = true
|
||||
npm.load(conf, function (er) {
|
||||
if (er) return errorHandler(er)
|
||||
if (
|
||||
!isGlobalNpmUpdate &&
|
||||
npm.config.get('update-notifier') &&
|
||||
!unsupported.checkVersion(process.version).unsupported
|
||||
) {
|
||||
const pkg = require('../package.json')
|
||||
let notifier = require('update-notifier')({pkg})
|
||||
const isCI = require('ci-info').isCI
|
||||
if (
|
||||
notifier.update &&
|
||||
notifier.update.latest !== pkg.version &&
|
||||
!isCI
|
||||
) {
|
||||
const color = require('ansicolors')
|
||||
const useColor = npm.config.get('color')
|
||||
const useUnicode = npm.config.get('unicode')
|
||||
const old = notifier.update.current
|
||||
const latest = notifier.update.latest
|
||||
let type = notifier.update.type
|
||||
if (useColor) {
|
||||
switch (type) {
|
||||
case 'major':
|
||||
type = color.red(type)
|
||||
break
|
||||
case 'minor':
|
||||
type = color.yellow(type)
|
||||
break
|
||||
case 'patch':
|
||||
type = color.green(type)
|
||||
break
|
||||
}
|
||||
}
|
||||
const changelog = `https://github.com/npm/cli/releases/tag/v${latest}`
|
||||
notifier.notify({
|
||||
message: `New ${type} version of ${pkg.name} available! ${
|
||||
useColor ? color.red(old) : old
|
||||
} ${useUnicode ? '→' : '->'} ${
|
||||
useColor ? color.green(latest) : latest
|
||||
}\n` +
|
||||
`${
|
||||
useColor ? color.yellow('Changelog:') : 'Changelog:'
|
||||
} ${
|
||||
useColor ? color.cyan(changelog) : changelog
|
||||
}\n` +
|
||||
`Run ${
|
||||
useColor
|
||||
? color.green(`npm install -g ${pkg.name}`)
|
||||
: `npm i -g ${pkg.name}`
|
||||
} to update!`
|
||||
})
|
||||
}
|
||||
}
|
||||
npm.commands[npm.command](npm.argv, function (err) {
|
||||
// https://genius.com/Lin-manuel-miranda-your-obedient-servant-lyrics
|
||||
if (
|
||||
!err &&
|
||||
npm.config.get('ham-it-up') &&
|
||||
!npm.config.get('json') &&
|
||||
!npm.config.get('parseable') &&
|
||||
npm.command !== 'completion'
|
||||
) {
|
||||
console.error(
|
||||
`\n ${
|
||||
npm.config.get('unicode') ? '🎵 ' : ''
|
||||
} I Have the Honour to Be Your Obedient Servant,${
|
||||
npm.config.get('unicode') ? '🎵 ' : ''
|
||||
} ~ npm ${
|
||||
npm.config.get('unicode') ? '📜🖋 ' : ''
|
||||
}\n`
|
||||
)
|
||||
}
|
||||
errorHandler.apply(this, arguments)
|
||||
})
|
||||
})
|
||||
})()
|
||||
19
website/node_modules/npm/bin/npm.cmd
generated
vendored
Normal file
19
website/node_modules/npm/bin/npm.cmd
generated
vendored
Normal file
@@ -0,0 +1,19 @@
|
||||
:: 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%" %*
|
||||
35
website/node_modules/npm/bin/npx
generated
vendored
Normal file
35
website/node_modules/npm/bin/npx
generated
vendored
Normal file
@@ -0,0 +1,35 @@
|
||||
#!/bin/sh
|
||||
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
|
||||
|
||||
basedir=`dirname "$0"`
|
||||
|
||||
case `uname` in
|
||||
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
|
||||
esac
|
||||
|
||||
NODE_EXE="$basedir/node.exe"
|
||||
if ! [ -x "$NODE_EXE" ]; then
|
||||
NODE_EXE=node
|
||||
fi
|
||||
|
||||
NPM_CLI_JS="$basedir/node_modules/npm/bin/npm-cli.js"
|
||||
NPX_CLI_JS="$basedir/node_modules/npm/bin/npx-cli.js"
|
||||
|
||||
case `uname` in
|
||||
*MINGW*)
|
||||
NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
|
||||
NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
|
||||
if [ -f "$NPM_PREFIX_NPX_CLI_JS" ]; then
|
||||
NPX_CLI_JS="$NPM_PREFIX_NPX_CLI_JS"
|
||||
fi
|
||||
;;
|
||||
*CYGWIN*)
|
||||
NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
|
||||
NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
|
||||
if [ -f "$NPM_PREFIX_NPX_CLI_JS" ]; then
|
||||
NPX_CLI_JS="$NPM_PREFIX_NPX_CLI_JS"
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
"$NODE_EXE" "$NPX_CLI_JS" "$@"
|
||||
8
website/node_modules/npm/bin/npx-cli.js
generated
vendored
Normal file
8
website/node_modules/npm/bin/npx-cli.js
generated
vendored
Normal file
@@ -0,0 +1,8 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
const npx = require('libnpx')
|
||||
const path = require('path')
|
||||
|
||||
const NPM_PATH = path.join(__dirname, 'npm-cli.js')
|
||||
|
||||
npx(npx.parseArgs(process.argv, NPM_PATH))
|
||||
20
website/node_modules/npm/bin/npx.cmd
generated
vendored
Normal file
20
website/node_modules/npm/bin/npx.cmd
generated
vendored
Normal file
@@ -0,0 +1,20 @@
|
||||
:: 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"
|
||||
SET "NPX_CLI_JS=%~dp0\node_modules\npm\bin\npx-cli.js"
|
||||
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_CLI_JS%" prefix -g') DO (
|
||||
SET "NPM_PREFIX_NPX_CLI_JS=%%F\node_modules\npm\bin\npx-cli.js"
|
||||
)
|
||||
IF EXIST "%NPM_PREFIX_NPX_CLI_JS%" (
|
||||
SET "NPX_CLI_JS=%NPM_PREFIX_NPX_CLI_JS%"
|
||||
)
|
||||
|
||||
"%NODE_EXE%" "%NPX_CLI_JS%" %*
|
||||
743
website/node_modules/npm/changelogs/CHANGELOG-1.md
generated
vendored
Normal file
743
website/node_modules/npm/changelogs/CHANGELOG-1.md
generated
vendored
Normal file
@@ -0,0 +1,743 @@
|
||||
### v1.4.29 (2015-10-29):
|
||||
|
||||
#### THINGS ARE HAPPENING IN LTS LAND
|
||||
|
||||
In a special one-off release as part of the [strategy to get a version of npm
|
||||
into Node LTS that works with the current
|
||||
registry](https://github.com/nodejs/LTS/issues/37), modify npm to print out
|
||||
this deprecation banner literally every time npm is invoked to do anything:
|
||||
|
||||
```
|
||||
npm WARN deprecated This version of npm lacks support for important features,
|
||||
npm WARN deprecated such as scoped packages, offered by the primary npm
|
||||
npm WARN deprecated registry. Consider upgrading to at least npm@2, if not the
|
||||
npm WARN deprecated latest stable version. To upgrade to npm@2, run:
|
||||
npm WARN deprecated
|
||||
npm WARN deprecated npm -g install npm@latest-2
|
||||
npm WARN deprecated
|
||||
npm WARN deprecated To upgrade to the latest stable version, run:
|
||||
npm WARN deprecated
|
||||
npm WARN deprecated npm -g install npm@latest
|
||||
npm WARN deprecated
|
||||
npm WARN deprecated (Depending on how Node.js was installed on your system, you
|
||||
npm WARN deprecated may need to prefix the preceding commands with `sudo`, or if
|
||||
npm WARN deprecated on Windows, run them from an Administrator prompt.)
|
||||
npm WARN deprecated
|
||||
npm WARN deprecated If you're running the version of npm bundled with
|
||||
npm WARN deprecated Node.js 0.10 LTS, be aware that the next version of 0.10 LTS
|
||||
npm WARN deprecated will be bundled with a version of npm@2, which has some small
|
||||
npm WARN deprecated backwards-incompatible changes made to `npm run-script` and
|
||||
npm WARN deprecated semver behavior.
|
||||
```
|
||||
|
||||
The message basically tells the tale: Node 0.10 will finally be getting
|
||||
`npm@2`, so those of you who haven't upgraded your build systems to deal with
|
||||
its (relatively small) breaking changes should do so now.
|
||||
|
||||
Also, this version doesn't even pretend that it can deal with scoped packages,
|
||||
which, given the confusing behavior of older versions of `npm@1.4`, where it
|
||||
would sometimes try to install packages from GitHub, is a distinct improvement.
|
||||
|
||||
There is no good reason for you as an end user to upgrade to this version of
|
||||
npm yourself.
|
||||
|
||||
* [`709e9b4`](https://github.com/npm/npm/commit/709e9b44f5df9817a1c4babfbf26a2329bd265fb)
|
||||
Print 20-line deprecation banner on all command invocations.
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* [`0c29d09`](https://github.com/npm/npm/commit/0c29d0906608e8e174bd30a7a245e19795326051)
|
||||
Crash out immediately with an exhortation to upgrade on attempts to use
|
||||
scoped packages. ([@othiym23](https://github.com/othiym23))
|
||||
|
||||
### v1.5.0-alpha-4 (2014-07-18):
|
||||
|
||||
* fall back to `_auth` config as default auth when using default registry
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* support for 'init.version' for those who don't want to deal with semver 0.0.x
|
||||
oddities ([@rvagg](https://github.com/rvagg))
|
||||
* [`be06213`](https://github.com/npm/npm/commit/be06213415f2d51a50d2c792b4cd0d3412a9a7b1)
|
||||
remove residual support for `win` log level
|
||||
([@aterris](https://github.com/aterris))
|
||||
|
||||
### v1.5.0-alpha-3 (2014-07-17):
|
||||
|
||||
* [`a3a85dd`](https://github.com/npm/npm/commit/a3a85dd004c9245a71ad2f0213bd1a9a90d64cd6)
|
||||
`--save` scoped packages correctly ([@othiym23](https://github.com/othiym23))
|
||||
* [`18a3385`](https://github.com/npm/npm/commit/18a3385bcf8bfb8312239216afbffb7eec759150)
|
||||
`npm-registry-client@3.0.2` ([@othiym23](https://github.com/othiym23))
|
||||
* [`375988b`](https://github.com/npm/npm/commit/375988b9bf5aa5170f06a790d624d31b1eb32c6d)
|
||||
invalid package names are an early error for optional deps
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* consistently use `node-package-arg` instead of arbitrary package spec
|
||||
splitting ([@othiym23](https://github.com/othiym23))
|
||||
|
||||
### v1.5.0-alpha-2 (2014-07-01):
|
||||
|
||||
* [`54cf625`](https://github.com/npm/npm/commit/54cf62534e3331e3f454e609e44f0b944e819283)
|
||||
fix handling for 301s in `npm-registry-client@3.0.1`
|
||||
([@Raynos](https://github.com/Raynos))
|
||||
* [`e410861`](https://github.com/npm/npm/commit/e410861c69a3799c1874614cb5b87af8124ff98d)
|
||||
don't crash if no username set on `whoami`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`0353dde`](https://github.com/npm/npm/commit/0353ddeaca8171aa7dbdd8102b7e2eb581a86406)
|
||||
respect `--json` for output ([@isaacs](https://github.com/isaacs))
|
||||
* [`b3d112a`](https://github.com/npm/npm/commit/b3d112ae190b984cc1779b9e6de92218f22380c6)
|
||||
outdated: Don't show headings if there's nothing to output
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`bb4b90c`](https://github.com/npm/npm/commit/bb4b90c80dbf906a1cb26d85bc0625dc2758acc3)
|
||||
outdated: Default to `latest` rather than `*` for unspecified deps
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.5.0-alpha-1 (2014-07-01):
|
||||
|
||||
* [`eef4884`](https://github.com/npm/npm/commit/eef4884d6487ee029813e60a5f9c54e67925d9fa)
|
||||
use the correct piece of the spec for GitHub shortcuts
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
|
||||
### v1.5.0-alpha-0 (2014-07-01):
|
||||
|
||||
* [`7f55057`](https://github.com/npm/npm/commit/7f55057807cfdd9ceaf6331968e666424f48116c)
|
||||
install scoped packages ([#5239](https://github.com/npm/npm/issues/5239))
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* [`0df7e16`](https://github.com/npm/npm/commit/0df7e16c0232d8f4d036ebf4ec3563215517caac)
|
||||
publish scoped packages ([#5239](https://github.com/npm/npm/issues/5239))
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* [`0689ba2`](https://github.com/npm/npm/commit/0689ba249b92b4c6279a26804c96af6f92b3a501)
|
||||
support (and save) --scope=@s config
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* [`f34878f`](https://github.com/npm/npm/commit/f34878fc4cee29901e4daf7bace94be01e25cad7)
|
||||
scope credentials to registry ([@othiym23](https://github.com/othiym23))
|
||||
* [`0ac7ca2`](https://github.com/npm/npm/commit/0ac7ca233f7a69751fe4386af6c4daa3ee9fc0da)
|
||||
capture and store bearer tokens when sent by registry
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* [`63c3277`](https://github.com/npm/npm/commit/63c3277f089b2c4417e922826bdc313ac854cad6)
|
||||
only delete files that are created by npm
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* [`4f54043`](https://github.com/npm/npm/commit/4f540437091d1cbca3915cd20c2da83c2a88bb8e)
|
||||
`npm-package-arg@2.0.0` ([@othiym23](https://github.com/othiym23))
|
||||
* [`9e1460e`](https://github.com/npm/npm/commit/9e1460e6ac9433019758481ec031358f4af4cd44)
|
||||
`read-package-json@1.2.3` ([@othiym23](https://github.com/othiym23))
|
||||
* [`719d8ad`](https://github.com/npm/npm/commit/719d8adb9082401f905ff4207ede494661f8a554)
|
||||
`fs-vacuum@1.2.1` ([@othiym23](https://github.com/othiym23))
|
||||
* [`9ef8fe4`](https://github.com/npm/npm/commit/9ef8fe4d6ead3acb3e88c712000e2d3a9480ebec)
|
||||
`async-some@1.0.0` ([@othiym23](https://github.com/othiym23))
|
||||
* [`a964f65`](https://github.com/npm/npm/commit/a964f65ab662107b62a4ca58535ce817e8cca331)
|
||||
`npmconf@2.0.1` ([@othiym23](https://github.com/othiym23))
|
||||
* [`113765b`](https://github.com/npm/npm/commit/113765bfb7d3801917c1d9f124b8b3d942bec89a)
|
||||
`npm-registry-client@3.0.0` ([@othiym23](https://github.com/othiym23))
|
||||
|
||||
### v1.4.28 (2014-09-12):
|
||||
|
||||
* [`f4540b6`](https://github.com/npm/npm/commit/f4540b6537a87e653d7495a9ddcf72949fdd4d14)
|
||||
[#6043](https://github.com/npm/npm/issues/6043) defer rollbacks until just
|
||||
before the CLI exits ([@isaacs](https://github.com/isaacs))
|
||||
* [`1eabfd5`](https://github.com/npm/npm/commit/1eabfd5c03f33c2bd28823714ff02059eeee3899)
|
||||
[#6043](https://github.com/npm/npm/issues/6043) `slide@1.1.6`: wait until all
|
||||
callbacks have finished before proceeding
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
|
||||
### v1.4.27 (2014-09-04):
|
||||
|
||||
* [`4cf3c8f`](https://github.com/npm/npm/commit/4cf3c8fd78c9e2693a5f899f50c28f4823c88e2e)
|
||||
[#6007](https://github.com/npm/npm/issues/6007) request@2.42.0: properly set
|
||||
headers on proxy requests ([@isaacs](https://github.com/isaacs))
|
||||
* [`403cb52`](https://github.com/npm/npm/commit/403cb526be1472bb7545fa8e62d4976382cdbbe5)
|
||||
[#6055](https://github.com/npm/npm/issues/6055) npmconf@1.1.8: restore
|
||||
case-insensitivity of environmental config
|
||||
([@iarna](https://github.com/iarna))
|
||||
|
||||
### v1.4.26 (2014-08-28):
|
||||
|
||||
* [`eceea95`](https://github.com/npm/npm/commit/eceea95c804fa15b18e91c52c0beb08d42a3e77d)
|
||||
`github-url-from-git@1.4.0`: add support for git+https and git+ssh
|
||||
([@stefanbuck](https://github.com/stefanbuck))
|
||||
* [`e561758`](https://github.com/npm/npm/commit/e5617587e7d7ab686192391ce55357dbc7fed0a3)
|
||||
`columnify@1.2.1` ([@othiym23](https://github.com/othiym23))
|
||||
* [`0c4fab3`](https://github.com/npm/npm/commit/0c4fab372ee76eab01dda83b6749429a8564902e)
|
||||
`cmd-shim@2.0.0`: upgrade to graceful-fs 3
|
||||
([@ForbesLindesay](https://github.com/ForbesLindesay))
|
||||
* [`2d69e4d`](https://github.com/npm/npm/commit/2d69e4d95777671958b5e08d3b2f5844109d73e4)
|
||||
`github-url-from-username-repo@1.0.0`: accept slashes in branch names
|
||||
([@robertkowalski](https://github.com/robertkowalski))
|
||||
* [`81f9b2b`](https://github.com/npm/npm/commit/81f9b2bac9d34c223ea093281ba3c495f23f10d1)
|
||||
ensure lifecycle spawn errors caught properly
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`bfaab8c`](https://github.com/npm/npm/commit/bfaab8c6e0942382a96b250634ded22454c36b5a)
|
||||
`npm-registry-client@2.0.7`: properly encode % in passwords
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`91cfb58`](https://github.com/npm/npm/commit/91cfb58dda851377ec604782263519f01fd96ad8)
|
||||
doc: Fix 'npm help index' ([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.25 (2014-08-21):
|
||||
|
||||
* [`64c0ec2`](https://github.com/npm/npm/commit/64c0ec241ef5d83761ca8de54acb3c41b079956e)
|
||||
`npm-registry-client@2.0.6`: Print the notification header returned by the
|
||||
registry, and make sure status codes are printed without gratuitous quotes
|
||||
around them.
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* [`a8ed12b`](https://github.com/npm/npm/commit/a8ed12b) `tar@1.0.1`:
|
||||
Add test for removing an extract target immediately after unpacking.
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`70fd11d`](https://github.com/npm/npm/commit/70fd11d)
|
||||
`lockfile@1.0.0`: Fix incorrect interaction between `wait`, `stale`,
|
||||
and `retries` options. Part 2 of race condition leading to `ENOENT`
|
||||
errors.
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`0072c4d`](https://github.com/npm/npm/commit/0072c4d)
|
||||
`fstream@1.0.2`: Fix a double-finish call which can result in excess
|
||||
FS operations after the `close` event. Part 2 of race condition
|
||||
leading to `ENOENT` errors.
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.24 (2014-08-14):
|
||||
|
||||
* [`9344bd9`](https://github.com/npm/npm/commit/9344bd9b2929b5c399a0e0e0b34d45bce7bc24bb)
|
||||
doc: add new changelog ([@othiym23](https://github.com/othiym23))
|
||||
* [`4be76fd`](https://github.com/npm/npm/commit/4be76fd65e895883c337a99f275ccc8c801adda3)
|
||||
doc: update version doc to include `pre-*` increment args
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`e4f2620`](https://github.com/npm/npm/commit/e4f262036080a282ad60e236a9aeebd39fde9fe4)
|
||||
build: add `make tag` to tag current release as `latest`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`ec2596a`](https://github.com/npm/npm/commit/ec2596a7cb626772780b25b0a94a7e547a812bd5)
|
||||
build: publish with `--tag=v1.4-next` ([@isaacs](https://github.com/isaacs))
|
||||
* [`9ee55f8`](https://github.com/npm/npm/commit/9ee55f892b8b473032a43c59912c5684fd1b39e6)
|
||||
build: add script to output `v1.4-next` publish tag
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`aecb56f`](https://github.com/npm/npm/commit/aecb56f95a84687ea46920a0b98aaa587fee1568)
|
||||
build: remove outdated `docpublish` make target
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`b57a9b7`](https://github.com/npm/npm/commit/b57a9b7ccd13e6b38831ed63595c8ea5763da247)
|
||||
build: remove unpublish step from `make publish`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`2c6acb9`](https://github.com/npm/npm/commit/2c6acb96c71c16106965d5cd829b67195dd673c7)
|
||||
install: rename `.gitignore` when unpacking foreign tarballs
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`22f3681`](https://github.com/npm/npm/commit/22f3681923e993a47fc1769ba735bfa3dd138082)
|
||||
cache: detect non-gzipped tar files more reliably
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.23 (2014-07-31):
|
||||
|
||||
* [`8dd11d1`](https://github.com/npm/npm/commit/8dd11d1) update several
|
||||
dependencies to avoid using `semver`s starting with 0.
|
||||
|
||||
### v1.4.22 (2014-07-31):
|
||||
|
||||
* [`d9a9e84`](https://github.com/npm/npm/commit/d9a9e84) `read-package-json@1.2.4`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`86f0340`](https://github.com/npm/npm/commit/86f0340)
|
||||
`github-url-from-git@1.2.0` ([@isaacs](https://github.com/isaacs))
|
||||
* [`a94136a`](https://github.com/npm/npm/commit/a94136a) `fstream@0.1.29`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`bb82d18`](https://github.com/npm/npm/commit/bb82d18) `glob@4.0.5`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`5b6bcf4`](https://github.com/npm/npm/commit/5b6bcf4) `cmd-shim@1.1.2`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`c2aa8b3`](https://github.com/npm/npm/commit/c2aa8b3) license: Cleaned up
|
||||
legalese with actual lawyer ([@isaacs](https://github.com/isaacs))
|
||||
* [`63fe0ee`](https://github.com/npm/npm/commit/63fe0ee) `init-package-json@1.0.0`
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.21 (2014-07-14):
|
||||
|
||||
* [`88f51aa`](https://github.com/npm/npm/commit/88f51aa27eb9a958d1fa7ec50fee5cfdedd05110)
|
||||
fix handling for 301s in `npm-registry-client@2.0.3`
|
||||
([@Raynos](https://github.com/Raynos))
|
||||
|
||||
### v1.4.20 (2014-07-02):
|
||||
|
||||
* [`0353dde`](https://github.com/npm/npm/commit/0353ddeaca8171aa7dbdd8102b7e2eb581a86406)
|
||||
respect `--json` for output ([@isaacs](https://github.com/isaacs))
|
||||
* [`b3d112a`](https://github.com/npm/npm/commit/b3d112ae190b984cc1779b9e6de92218f22380c6)
|
||||
outdated: Don't show headings if there's nothing to output
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* [`bb4b90c`](https://github.com/npm/npm/commit/bb4b90c80dbf906a1cb26d85bc0625dc2758acc3)
|
||||
outdated: Default to `latest` rather than `*` for unspecified deps
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.19 (2014-07-01):
|
||||
|
||||
* [`f687433`](https://github.com/npm/npm/commit/f687433) relative URLS for
|
||||
working non-root registry URLS ([@othiym23](https://github.com/othiym23))
|
||||
* [`bea190c`](https://github.com/npm/npm/commit/bea190c)
|
||||
[#5591](https://github.com/npm/npm/issues/5591) bump nopt and npmconf
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.18 (2014-06-29):
|
||||
|
||||
* Bump glob dependency from 4.0.2 to 4.0.3. It now uses graceful-fs when
|
||||
available, increasing resilience to [various filesystem
|
||||
errors](https://github.com/isaacs/node-graceful-fs#improvements-over-fs-module).
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.17 (2014-06-27):
|
||||
|
||||
* replace escape codes with ansicolors
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
* Allow to build all the docs OOTB. ([@GeJ](https://github.com/GeJ))
|
||||
* Use core.longpaths on win32 git - fixes
|
||||
[#5525](https://github.com/npm/npm/issues/5525) ([@bmeck](https://github.com/bmeck))
|
||||
* `npmconf@1.1.2` ([@isaacs](https://github.com/isaacs))
|
||||
* Consolidate color sniffing in config/log loading process
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* add verbose log when project config file is ignored
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* npmconf: Float patch to remove 'scope' from config defs
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* doc: npm-explore can't handle a version
|
||||
([@robertkowalski](https://github.com/robertkowalski))
|
||||
* Add user-friendly errors for ENOSPC and EROFS.
|
||||
([@voodootikigod](https://github.com/voodootikigod))
|
||||
* bump tar and fstream deps ([@isaacs](https://github.com/isaacs))
|
||||
* Run the npm-registry-couchapp tests along with npm tests
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.2.8000 (2014-06-17):
|
||||
|
||||
* Same as v1.4.16, but with the spinner disabled, and a version number that
|
||||
starts with v1.2.
|
||||
|
||||
### v1.4.16 (2014-06-17):
|
||||
|
||||
* `npm-registry-client@2.0.2` ([@isaacs](https://github.com/isaacs))
|
||||
* `fstream@0.1.27` ([@isaacs](https://github.com/isaacs))
|
||||
* `sha@1.2.4` ([@isaacs](https://github.com/isaacs))
|
||||
* `rimraf@2.2.8` ([@isaacs](https://github.com/isaacs))
|
||||
* `npmlog@1.0.1` ([@isaacs](https://github.com/isaacs))
|
||||
* `npm-registry-client@2.0.1` ([@isaacs](https://github.com/isaacs))
|
||||
* removed redundant dependency ([@othiym23](https://github.com/othiym23))
|
||||
* `npmconf@1.0.5` ([@isaacs](https://github.com/isaacs))
|
||||
* Properly handle errors that can occur in the config-loading process
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.15 (2014-06-10):
|
||||
|
||||
* cache: atomic de-race-ified package.json writing
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* `fstream@0.1.26` ([@isaacs](https://github.com/isaacs))
|
||||
* `graceful-fs@3.0.2` ([@isaacs](https://github.com/isaacs))
|
||||
* `osenv@0.1.0` ([@isaacs](https://github.com/isaacs))
|
||||
* Only spin the spinner when we're fetching stuff
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* Update `osenv@0.1.0` which removes ~/tmp as possible tmp-folder
|
||||
([@robertkowalski](https://github.com/robertkowalski))
|
||||
* `ini@1.2.1` ([@isaacs](https://github.com/isaacs))
|
||||
* `graceful-fs@3` ([@isaacs](https://github.com/isaacs))
|
||||
* Update glob and things depending on glob
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* github-url-from-username-repo and read-package-json updates
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* `editor@0.1.0` ([@isaacs](https://github.com/isaacs))
|
||||
* `columnify@1.1.0` ([@isaacs](https://github.com/isaacs))
|
||||
* bump ansi and associated deps ([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.14 (2014-06-05):
|
||||
|
||||
* char-spinner: update to not bork windows
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.13 (2014-05-23):
|
||||
|
||||
* Fix `npm install` on a tarball.
|
||||
([`ed3abf1`](https://github.com/npm/npm/commit/ed3abf1aa10000f0f687330e976d78d1955557f6),
|
||||
[#5330](https://github.com/npm/npm/issues/5330),
|
||||
[@othiym23](https://github.com/othiym23))
|
||||
* Fix an issue with the spinner on Node 0.8.
|
||||
([`9f00306`](https://github.com/npm/npm/commit/9f003067909440390198c0b8f92560d84da37762),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Re-add `npm.commands.cache.clean` and `npm.commands.cache.read` APIs, and
|
||||
document `npm.commands.cache.*` as npm-cache(3).
|
||||
([`e06799e`](https://github.com/npm/npm/commit/e06799e77e60c1fc51869619083a25e074d368b3),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.12 (2014-05-23):
|
||||
|
||||
* remove normalize-package-data from top level, de-^-ify inflight dep
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* Always sort saved bundleDependencies ([@isaacs](https://github.com/isaacs))
|
||||
* add inflight to bundledDependencies
|
||||
([@othiym23](https://github.com/othiym23))
|
||||
|
||||
### v1.4.11 (2014-05-22):
|
||||
|
||||
* fix `npm ls` labeling issue
|
||||
* `node-gyp@0.13.1`
|
||||
* default repository to https:// instead of git://
|
||||
* addLocalTarball: Remove extraneous unpack
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* Massive cache folder refactor ([@othiym23](https://github.com/othiym23) and
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Busy Spinner, no http noise ([@isaacs](https://github.com/isaacs))
|
||||
* Per-project .npmrc file support ([@isaacs](https://github.com/isaacs))
|
||||
* `npmconf@1.0.0`, Refactor config/uid/prefix loading process
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* Allow once-disallowed characters in passwords
|
||||
([@isaacs](https://github.com/isaacs))
|
||||
* Send npm version as 'version' header ([@isaacs](https://github.com/isaacs))
|
||||
* fix cygwin encoding issue (Karsten Tinnefeld)
|
||||
* Allow non-github repositories with `npm repo`
|
||||
([@evanlucas](https://github.com/evanlucas))
|
||||
* Allow peer deps to be satisfied by grandparent
|
||||
* Stop optional deps moving into deps on `update --save`
|
||||
([@timoxley](https://github.com/timoxley))
|
||||
* Ensure only matching deps update with `update --save*`
|
||||
([@timoxley](https://github.com/timoxley))
|
||||
* Add support for `prerelease`, `preminor`, `prepatch` to `npm version`
|
||||
|
||||
### v1.4.10 (2014-05-05):
|
||||
|
||||
* Don't set referer if already set
|
||||
* fetch: Send referer and npm-session headers
|
||||
* `run-script`: Support `--parseable` and `--json`
|
||||
* list runnable scripts ([@evanlucas](https://github.com/evanlucas))
|
||||
* Use marked instead of ronn for html docs
|
||||
|
||||
### v1.4.9 (2014-05-01):
|
||||
|
||||
* Send referer header (with any potentially private stuff redacted)
|
||||
* Fix critical typo bug in previous npm release
|
||||
|
||||
### v1.4.8 (2014-05-01):
|
||||
|
||||
* Check SHA before using files from cache
|
||||
* adduser: allow change of the saved password
|
||||
* Make `npm install` respect `config.unicode`
|
||||
* Fix lifecycle to pass `Infinity` for config env value
|
||||
* Don't return 0 exit code on invalid command
|
||||
* cache: Handle 404s and other HTTP errors as errors
|
||||
* Resolve ~ in path configs to env.HOME
|
||||
* Include npm version in default user-agent conf
|
||||
* npm init: Use ISC as default license, use save-prefix for deps
|
||||
* Many test and doc fixes
|
||||
|
||||
### v1.4.7 (2014-04-15):
|
||||
|
||||
* Add `--save-prefix` option that can be used to override the default of `^`
|
||||
when using `npm install --save` and its counterparts.
|
||||
([`64eefdf`](https://github.com/npm/npm/commit/64eefdfe26bb27db8dc90e3ab5d27a5ef18a4470),
|
||||
[@thlorenz](https://github.com/thlorenz))
|
||||
* Allow `--silent` to silence the echoing of commands that occurs with `npm
|
||||
run`.
|
||||
([`c95cf08`](https://github.com/npm/npm/commit/c95cf086e5b97dbb48ff95a72517b203a8f29eab),
|
||||
[@Raynos](https://github.com/Raynos))
|
||||
* Some speed improvements to the cache, which should improve install times.
|
||||
([`cb94310`](https://github.com/npm/npm/commit/cb94310a6adb18cb7b881eacb8d67171eda8b744),
|
||||
[`3b0870f`](https://github.com/npm/npm/commit/3b0870fb2f40358b3051abdab6be4319d196b99d),
|
||||
[`120f5a9`](https://github.com/npm/npm/commit/120f5a93437bbbea9249801574a2f33e44e81c33),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Improve ability to retry registry requests when a subset of the registry
|
||||
servers are down.
|
||||
([`4a5257d`](https://github.com/npm/npm/commit/4a5257de3870ac3dafa39667379f19f6dcd6093e),
|
||||
https://github.com/npm/npm-registry-client/commit/7686d02cb0b844626d6a401e58c0755ef3bc8432,
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Fix marking of peer dependencies as extraneous.
|
||||
([`779b164`](https://github.com/npm/npm/commit/779b1649764607b062c031c7e5c972151b4a1754),
|
||||
https://github.com/npm/read-installed/commit/6680ba6ef235b1ca3273a00b70869798ad662ddc,
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Fix npm crashing when doing `npm shrinkwrap` in the presence of a
|
||||
`package.json` with no dependencies.
|
||||
([`a9d9fa5`](https://github.com/npm/npm/commit/a9d9fa5ad3b8c925a589422b7be28d2735f320b0),
|
||||
[@kislyuk](https://github.com/kislyuk))
|
||||
* Fix error when using `npm view` on packages that have no versions or have
|
||||
been unpublished.
|
||||
([`94df2f5`](https://github.com/npm/npm/commit/94df2f56d684b35d1df043660180fc321b743dc8),
|
||||
[@juliangruber](https://github.com/juliangruber);
|
||||
[`2241a09`](https://github.com/npm/npm/commit/2241a09c843669c70633c399ce698cec3add40b3),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.6 (2014-03-19):
|
||||
|
||||
* Fix extraneous package detection to work in more cases.
|
||||
([`f671286`](https://github.com/npm/npm/commit/f671286), npm/read-installed#20,
|
||||
[@LaurentVB](https://github.com/LaurentVB))
|
||||
|
||||
### v1.4.5 (2014-03-18):
|
||||
|
||||
* Sort dependencies in `package.json` when doing `npm install --save` and all
|
||||
its variants.
|
||||
([`6fd6ff7`](https://github.com/npm/npm/commit/6fd6ff7e536ea6acd33037b1878d4eca1f931985),
|
||||
[@domenic](https://github.com/domenic))
|
||||
* Add `--save-exact` option, usable alongside `--save` and its variants, which
|
||||
will write the exact version number into `package.json` instead of the
|
||||
appropriate semver-compatibility range.
|
||||
([`17f07df`](https://github.com/npm/npm/commit/17f07df8ad8e594304c2445bf7489cb53346f2c5),
|
||||
[@timoxley](https://github.com/timoxley))
|
||||
* Accept gzipped content from the registry to speed up downloads and save
|
||||
bandwidth.
|
||||
([`a3762de`](https://github.com/npm/npm/commit/a3762de843b842be8fa0ab57cdcd6b164f145942),
|
||||
npm/npm-registry-client#40, [@fengmk2](https://github.com/fengmk2))
|
||||
* Fix `npm ls`'s `--depth` and `--log` options.
|
||||
([`1d29b17`](https://github.com/npm/npm/commit/1d29b17f5193d52a5c4faa412a95313dcf41ed91),
|
||||
npm/read-installed#13, [@zertosh](https://github.com/zertosh))
|
||||
* Fix "Adding a cache directory to the cache will make the world implode" in
|
||||
certain cases.
|
||||
([`9a4b2c4`](https://github.com/npm/npm/commit/9a4b2c4667c2b1e0054e3d5611ab86acb1760834),
|
||||
domenic/path-is-inside#1, [@pmarques](https://github.com/pmarques))
|
||||
* Fix readmes not being uploaded in certain rare cases.
|
||||
([`527b72c`](https://github.com/npm/npm/commit/527b72cca6c55762b51e592c48a9f28cc7e2ff8b),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.4 (2014-02-20):
|
||||
|
||||
* Add `npm t` as an alias for `npm test` (which is itself an alias for `npm run
|
||||
test`, or even `npm run-script test`). We like making running your tests
|
||||
easy. ([`14e650b`](https://github.com/npm/npm/commit/14e650bce0bfebba10094c961ac104a61417a5de), [@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.3 (2014-02-16):
|
||||
|
||||
* Add back `npm prune --production`, which was removed in 1.3.24.
|
||||
([`acc4d02`](https://github.com/npm/npm/commit/acc4d023c57d07704b20a0955e4bf10ee91bdc83),
|
||||
[@davglass](https://github.com/davglass))
|
||||
* Default `npm install --save` and its counterparts to use the `^` version
|
||||
specifier, instead of `~`.
|
||||
([`0a3151c`](https://github.com/npm/npm/commit/0a3151c9cbeb50c1c65895685c2eabdc7e2608dc),
|
||||
[@mikolalysenko](https://github.com/mikolalysenko))
|
||||
* Make `npm shrinkwrap` output dependencies in a sorted order, so that diffs
|
||||
between shrinkwrap files should be saner now.
|
||||
([`059b2bf`](https://github.com/npm/npm/commit/059b2bfd06ae775205a37257dca80142596a0113),
|
||||
[@Raynos](https://github.com/Raynos))
|
||||
* Fix `npm dedupe` not correctly respecting dependency constraints.
|
||||
([`86028e9`](https://github.com/npm/npm/commit/86028e9fd8524d5e520ce01ba2ebab5a030103fc),
|
||||
[@rafeca](https://github.com/rafeca))
|
||||
* Fix `npm ls` giving spurious warnings when you used `"latest"` as a version
|
||||
specifier.
|
||||
(https://github.com/npm/read-installed/commit/d2956400e0386931c926e0f30c334840e0938f14,
|
||||
[@bajtos](https://github.com/bajtos))
|
||||
* Fixed a bug where using `npm link` on packages without a `name` value could
|
||||
cause npm to delete itself.
|
||||
([`401a642`](https://github.com/npm/npm/commit/401a64286aa6665a94d1d2f13604f7014c5fce87),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Fixed `npm install ./pkg@1.2.3` to actually install the directory at
|
||||
`pkg@1.2.3`; before it would try to find version `1.2.3` of the package
|
||||
`./pkg` in the npm registry.
|
||||
([`46d8768`](https://github.com/npm/npm/commit/46d876821d1dd94c050d5ebc86444bed12c56739),
|
||||
[@rlidwka](https://github.com/rlidwka); see also
|
||||
[`f851b79`](https://github.com/npm/npm/commit/f851b79a71d9a5f5125aa85877c94faaf91bea5f))
|
||||
* Fix `npm outdated` to respect the `color` configuration option.
|
||||
([`d4f6f3f`](https://github.com/npm/npm/commit/d4f6f3ff83bd14fb60d3ac6392cb8eb6b1c55ce1),
|
||||
[@timoxley](https://github.com/timoxley))
|
||||
* Fix `npm outdated --parseable`.
|
||||
([`9575a23`](https://github.com/npm/npm/commit/9575a23f955ce3e75b509c89504ef0bd707c8cf6),
|
||||
[@yhpark](https://github.com/yhpark))
|
||||
* Fix a lockfile-related errors when using certain Git URLs.
|
||||
([`164b97e`](https://github.com/npm/npm/commit/164b97e6089f64e686db7a9a24016f245effc37f),
|
||||
[@nigelzor](https://github.com/nigelzor))
|
||||
|
||||
### v1.4.2 (2014-02-13):
|
||||
|
||||
* Fixed an issue related to mid-publish GET requests made against the registry.
|
||||
(https://github.com/npm/npm-registry-client/commit/acbec48372bc1816c67c9e7cbf814cf50437ff93,
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.1 (2014-02-13):
|
||||
|
||||
* Fix `npm shrinkwrap` forgetting to shrinkwrap dependencies that were also
|
||||
development dependencies.
|
||||
([`9c575c5`](https://github.com/npm/npm/commit/9c575c56efa9b0c8b0d4a17cb9c1de3833004bcd),
|
||||
[@diwu1989](https://github.com/diwu1989))
|
||||
* Fixed publishing of pre-existing packages with uppercase characters in their
|
||||
name.
|
||||
(https://github.com/npm/npm-registry-client/commit/9345d3b6c3d8510dd5c4418f27ee1fce59acebad,
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.4.0 (2014-02-12):
|
||||
|
||||
* Remove `npm publish --force`. See
|
||||
https://github.com/npm/npmjs.org/issues/148.
|
||||
([@isaacs](https://github.com/isaacs),
|
||||
npm/npm-registry-client@2c8dba990de6a59af6545b75cc00a6dc12777c2a)
|
||||
* Other changes to the registry client related to saved configs and couch
|
||||
logins. ([@isaacs](https://github.com/isaacs);
|
||||
npm/npm-registry-client@25e2b019a1588155e5f87d035c27e79963b75951,
|
||||
npm/npm-registry-client@9e41e9101b68036e0f078398785f618575f3cdde,
|
||||
npm/npm-registry-client@2c8dba990de6a59af6545b75cc00a6dc12777c2a)
|
||||
* Show an error to the user when doing `npm update` and the `package.json`
|
||||
specifies a version that does not exist.
|
||||
([@evanlucas](https://github.com/evanlucas),
|
||||
[`027a33a`](https://github.com/npm/npm/commit/027a33a5c594124cc1d82ddec5aee2c18bc8dc32))
|
||||
* Fix some issues with cache ownership in certain installation configurations.
|
||||
([@outcoldman](https://github.com/outcoldman),
|
||||
[`a132690`](https://github.com/npm/npm/commit/a132690a2876cda5dcd1e4ca751f21dfcb11cb9e))
|
||||
* Fix issues where GitHub shorthand dependencies `user/repo` were not always
|
||||
treated the same as full Git URLs.
|
||||
([@robertkowalski](https://github.com/robertkowalski),
|
||||
https://github.com/meryn/normalize-package-data/commit/005d0b637aec1895117fcb4e3b49185eebf9e240)
|
||||
|
||||
### v1.3.26 (2014-02-02):
|
||||
|
||||
* Fixes and updates to publishing code
|
||||
([`735427a`](https://github.com/npm/npm/commit/735427a69ba4fe92aafa2d88f202aaa42920a9e2)
|
||||
and
|
||||
[`c0ac832`](https://github.com/npm/npm/commit/c0ac83224d49aa62e55577f8f27d53bbfd640dc5),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Fix `npm bugs` with no arguments.
|
||||
([`b99d465`](https://github.com/npm/npm/commit/b99d465221ac03bca30976cbf4d62ca80ab34091),
|
||||
[@Hoops](https://github.com/Hoops))
|
||||
|
||||
### v1.3.25 (2014-01-25):
|
||||
|
||||
* Remove gubblebum blocky font from documentation headers.
|
||||
([`6940c9a`](https://github.com/npm/npm/commit/6940c9a100160056dc6be8f54a7ad7fa8ceda7e2),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
|
||||
### v1.3.24 (2014-01-19):
|
||||
|
||||
* Make the search output prettier, with nice truncated columns, and a `--long`
|
||||
option to create wrapping columns.
|
||||
([`20439b2`](https://github.com/npm/npm/commit/20439b2) and
|
||||
[`3a6942d`](https://github.com/npm/npm/commit/3a6942d),
|
||||
[@timoxley](https://github.com/timoxley))
|
||||
* Support multiple packagenames in `npm docs`.
|
||||
([`823010b`](https://github.com/npm/npm/commit/823010b),
|
||||
[@timoxley](https://github.com/timoxley))
|
||||
* Fix the `npm adduser` bug regarding "Error: default value must be string or
|
||||
number" again. ([`b9b4248`](https://github.com/npm/npm/commit/b9b4248),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Fix `scripts` entries containing whitespaces on Windows.
|
||||
([`80282ed`](https://github.com/npm/npm/commit/80282ed),
|
||||
[@robertkowalski](https://github.com/robertkowalski))
|
||||
* Fix `npm update` for Git URLs that have credentials in them
|
||||
([`93fc364`](https://github.com/npm/npm/commit/93fc364),
|
||||
[@danielsantiago](https://github.com/danielsantiago))
|
||||
* Fix `npm install` overwriting `npm link`-ed dependencies when they are tagged
|
||||
Git dependencies. ([`af9bbd9`](https://github.com/npm/npm/commit/af9bbd9),
|
||||
[@evanlucas](https://github.com/evanlucas))
|
||||
* Remove `npm prune --production` since it buggily removed some dependencies
|
||||
that were necessary for production; see
|
||||
[#4509](https://github.com/npm/npm/issues/4509). Hopefully it can make its
|
||||
triumphant return, one day.
|
||||
([`1101b6a`](https://github.com/npm/npm/commit/1101b6a),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
|
||||
Dependency updates:
|
||||
* [`909cccf`](https://github.com/npm/npm/commit/909cccf) `read-package-json@1.1.6`
|
||||
* [`a3891b6`](https://github.com/npm/npm/commit/a3891b6) `rimraf@2.2.6`
|
||||
* [`ac6efbc`](https://github.com/npm/npm/commit/ac6efbc) `sha@1.2.3`
|
||||
* [`dd30038`](https://github.com/npm/npm/commit/dd30038) `node-gyp@0.12.2`
|
||||
* [`c8c3ebe`](https://github.com/npm/npm/commit/c8c3ebe) `npm-registry-client@0.3.3`
|
||||
* [`4315286`](https://github.com/npm/npm/commit/4315286) `npmconf@0.1.12`
|
||||
|
||||
### v1.3.23 (2014-01-03):
|
||||
|
||||
* Properly handle installations that contained a certain class of circular
|
||||
dependencies.
|
||||
([`5dc93e8`](https://github.com/npm/npm/commit/5dc93e8c82604c45b6067b1acf1c768e0bfce754),
|
||||
[@substack](https://github.com/substack))
|
||||
|
||||
### v1.3.22 (2013-12-25):
|
||||
|
||||
* Fix a critical bug in `npm adduser` that would manifest in the error message
|
||||
"Error: default value must be string or number."
|
||||
([`fba4bd2`](https://github.com/npm/npm/commit/fba4bd24bc2ab00ccfeda2043aa53af7d75ef7ce),
|
||||
[@isaacs](https://github.com/isaacs))
|
||||
* Allow `npm bugs` in the current directory to open the current package's bugs
|
||||
URL.
|
||||
([`d04cf64`](https://github.com/npm/npm/commit/d04cf6483932c693452f3f778c2fa90f6153a4af),
|
||||
[@evanlucas](https://github.com/evanlucas))
|
||||
* Several fixes to various error messages to include more useful or updated
|
||||
information.
|
||||
([`1e6f2a7`](https://github.com/npm/npm/commit/1e6f2a72ca058335f9f5e7ca22d01e1a8bb0f9f7),
|
||||
[`ff46366`](https://github.com/npm/npm/commit/ff46366bd40ff0ef33c7bac8400bc912c56201d1),
|
||||
[`8b4bb48`](https://github.com/npm/npm/commit/8b4bb4815d80a3612186dc5549d698e7b988eb03);
|
||||
[@rlidwka](https://github.com/rlidwka),
|
||||
[@evanlucas](https://github.com/evanlucas))
|
||||
|
||||
### v1.3.21 (2013-12-17):
|
||||
|
||||
* Fix a critical bug that prevented publishing due to incorrect hash
|
||||
calculation.
|
||||
([`4ca4a2c`](https://github.com/npm/npm-registry-client/commit/4ca4a2c6333144299428be6b572e2691aa59852e),
|
||||
[@dominictarr](https://github.com/dominictarr))
|
||||
|
||||
### v1.3.20 (2013-12-17):
|
||||
|
||||
* Fixes a critical bug in v1.3.19. Thankfully, due to that bug, no one could
|
||||
install npm v1.3.19 :)
|
||||
|
||||
### v1.3.19 (2013-12-16):
|
||||
|
||||
* Adds atomic PUTs for publishing packages, which should result in far fewer
|
||||
requests and less room for replication errors on the server-side.
|
||||
|
||||
### v1.3.18 (2013-12-16):
|
||||
|
||||
* Added an `--ignore-scripts` option, which will prevent `package.json` scripts
|
||||
from being run. Most notably, this will work on `npm install`, so e.g. `npm
|
||||
install --ignore-scripts` will not run preinstall and prepublish scripts.
|
||||
([`d7e67bf`](https://github.com/npm/npm/commit/d7e67bf0d94b085652ec1c87d595afa6f650a8f6),
|
||||
[@sqs](https://github.com/sqs))
|
||||
* Fixed a bug introduced in 1.3.16 that would manifest with certain cache
|
||||
configurations, by causing spurious errors saying "Adding a cache directory
|
||||
to the cache will make the world implode."
|
||||
([`966373f`](https://github.com/npm/npm/commit/966373fad8d741637f9744882bde9f6e94000865),
|
||||
[@domenic](https://github.com/domenic))
|
||||
* Re-fixed the multiple download of URL dependencies, whose fix was reverted in
|
||||
1.3.17.
|
||||
([`a362c3f`](https://github.com/npm/npm/commit/a362c3f1919987419ed8a37c8defa19d2e6697b0),
|
||||
[@spmason](https://github.com/spmason))
|
||||
|
||||
### v1.3.17 (2013-12-11):
|
||||
|
||||
* This release reverts
|
||||
[`644c2ff`](https://github.com/npm/npm/commit/644c2ff3e3d9c93764f7045762477f48864d64a7),
|
||||
which avoided re-downloading URL and shinkwrap dependencies when doing `npm
|
||||
install`. You can see the in-depth reasoning in
|
||||
[`d8c907e`](https://github.com/npm/npm/commit/d8c907edc2019b75cff0f53467e34e0ffd7e5fba);
|
||||
the problem was, that the patch changed the behavior of `npm install -f` to
|
||||
reinstall all dependencies.
|
||||
* A new version of the no-re-downloading fix has been submitted as
|
||||
[#4303](https://github.com/npm/npm/issues/4303) and will hopefully be
|
||||
included in the next release.
|
||||
|
||||
### v1.3.16 (2013-12-11):
|
||||
|
||||
* Git URL dependencies are now updated on `npm install`, fixing a two-year old
|
||||
bug
|
||||
([`5829ecf`](https://github.com/npm/npm/commit/5829ecf032b392d2133bd351f53d3c644961396b),
|
||||
[@robertkowalski](https://github.com/robertkowalski)). Additional progress on
|
||||
reducing the resulting Git-related I/O is tracked as
|
||||
[#4191](https://github.com/npm/npm/issues/4191), but for now, this will be a
|
||||
big improvement.
|
||||
* Added a `--json` mode to `npm outdated` to give a parseable output.
|
||||
([`0b6c9b7`](https://github.com/npm/npm/commit/0b6c9b7c8c5579f4d7d37a0c24d9b7a12ccbe5fe),
|
||||
[@yyx990803](https://github.com/yyx990803))
|
||||
* Made `npm outdated` much prettier and more useful. It now outputs a
|
||||
color-coded and easy-to-read table.
|
||||
([`fd3017f`](https://github.com/npm/npm/commit/fd3017fc3e9d42acf6394a5285122edb4dc16106),
|
||||
[@quimcalpe](https://github.com/quimcalpe))
|
||||
* Added the `--depth` option to `npm outdated`, so that e.g. you can do `npm
|
||||
outdated --depth=0` to show only top-level outdated dependencies.
|
||||
([`1d184ef`](https://github.com/npm/npm/commit/1d184ef3f4b4bc309d38e9128732e3e6fb46d49c),
|
||||
[@yyx990803](https://github.com/yyx990803))
|
||||
* Added a `--no-git-tag-version` option to `npm version`, for doing the usual
|
||||
job of `npm version` minus the Git tagging. This could be useful if you need
|
||||
to increase the version in other related files before actually adding the
|
||||
tag.
|
||||
([`59ca984`](https://github.com/npm/npm/commit/59ca9841ba4f4b2f11b8e72533f385c77ae9f8bd),
|
||||
[@evanlucas](https://github.com/evanlucas))
|
||||
* Made `npm repo` and `npm docs` work without any arguments, adding them to the
|
||||
list of npm commands that work on the package in the current directory when
|
||||
invoked without arguments.
|
||||
([`bf9048e`](https://github.com/npm/npm/commit/bf9048e2fa16d43fbc4b328d162b0a194ca484e8),
|
||||
[@robertkowalski](https://github.com/robertkowalski);
|
||||
[`07600d0`](https://github.com/npm/npm/commit/07600d006c652507cb04ac0dae9780e35073dd67),
|
||||
[@wilmoore](https://github.com/wilmoore)). There are a few other commands we
|
||||
still want to implement this for; see
|
||||
[#4204](https://github.com/npm/npm/issues/4204).
|
||||
* Pass through the `GIT_SSL_NO_VERIFY` environment variable to Git, if it is
|
||||
set; we currently do this with a few other environment variables, but we
|
||||
missed that one.
|
||||
([`c625de9`](https://github.com/npm/npm/commit/c625de91770df24c189c77d2e4bc821f2265efa8),
|
||||
[@arikon](https://github.com/arikon))
|
||||
* Fixed `npm dedupe` on Windows due to incorrect path separators being used
|
||||
([`7677de4`](https://github.com/npm/npm/commit/7677de4583100bc39407093ecc6bc13715bf8161),
|
||||
[@mcolyer](https://github.com/mcolyer)).
|
||||
* Fixed the `npm help` command when multiple words were searched for; it
|
||||
previously gave a `ReferenceError`.
|
||||
([`6a28dd1`](https://github.com/npm/npm/commit/6a28dd147c6957a93db12b1081c6e0da44fe5e3c),
|
||||
[@dereckson](https://github.com/dereckson))
|
||||
* Stopped re-downloading URL and shrinkwrap dependencies, as demonstrated in
|
||||
[#3463](https://github.com/npm/npm/issues/3463)
|
||||
([`644c2ff`](https://github.com/isaacs/npm/commit/644c2ff3e3d9c93764f7045762477f48864d64a7),
|
||||
[@spmason](https://github.com/spmason)). You can use the `--force` option to
|
||||
force re-download and installation of all dependencies.
|
||||
5344
website/node_modules/npm/changelogs/CHANGELOG-2.md
generated
vendored
Normal file
5344
website/node_modules/npm/changelogs/CHANGELOG-2.md
generated
vendored
Normal file
File diff suppressed because it is too large
Load Diff
5245
website/node_modules/npm/changelogs/CHANGELOG-3.md
generated
vendored
Normal file
5245
website/node_modules/npm/changelogs/CHANGELOG-3.md
generated
vendored
Normal file
File diff suppressed because it is too large
Load Diff
1566
website/node_modules/npm/changelogs/CHANGELOG-4.md
generated
vendored
Normal file
1566
website/node_modules/npm/changelogs/CHANGELOG-4.md
generated
vendored
Normal file
File diff suppressed because it is too large
Load Diff
2360
website/node_modules/npm/changelogs/CHANGELOG-5.md
generated
vendored
Normal file
2360
website/node_modules/npm/changelogs/CHANGELOG-5.md
generated
vendored
Normal file
File diff suppressed because it is too large
Load Diff
33
website/node_modules/npm/configure
generated
vendored
Normal file
33
website/node_modules/npm/configure
generated
vendored
Normal file
@@ -0,0 +1,33 @@
|
||||
#!/bin/bash
|
||||
|
||||
# set configurations that will be "sticky" on this system,
|
||||
# surviving npm self-updates.
|
||||
|
||||
CONFIGS=()
|
||||
i=0
|
||||
|
||||
# get the location of this file.
|
||||
unset CDPATH
|
||||
CONFFILE=$(cd $(dirname "$0"); pwd -P)/npmrc
|
||||
|
||||
while [ $# -gt 0 ]; do
|
||||
conf="$1"
|
||||
case $conf in
|
||||
--help)
|
||||
echo "./configure --param=value ..."
|
||||
exit 0
|
||||
;;
|
||||
--*)
|
||||
CONFIGS[$i]="${conf:2}"
|
||||
;;
|
||||
*)
|
||||
CONFIGS[$i]="$conf"
|
||||
;;
|
||||
esac
|
||||
let i++
|
||||
shift
|
||||
done
|
||||
|
||||
for c in "${CONFIGS[@]}"; do
|
||||
echo "$c" >> "$CONFFILE"
|
||||
done
|
||||
76
website/node_modules/npm/doc/cli/npm-access.md
generated
vendored
Normal file
76
website/node_modules/npm/doc/cli/npm-access.md
generated
vendored
Normal file
@@ -0,0 +1,76 @@
|
||||
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 you have two-factor authentication enabled then you'll have to pass in an
|
||||
otp with `--otp` when making access changes.
|
||||
|
||||
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)
|
||||
85
website/node_modules/npm/doc/cli/npm-adduser.md
generated
vendored
Normal file
85
website/node_modules/npm/doc/cli/npm-adduser.md
generated
vendored
Normal file
@@ -0,0 +1,85 @@
|
||||
npm-adduser(1) -- Add a registry user account
|
||||
=============================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm adduser [--registry=url] [--scope=@orgname] [--always-auth] [--auth-type=legacy]
|
||||
|
||||
aliases: login, add-user
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Create or verify a user named `<username>` in the specified registry, and
|
||||
save the credentials to the `.npmrc` file. If no registry is specified,
|
||||
the default registry will be used (see `npm-config(7)`).
|
||||
|
||||
The username, password, and email are read in from prompts.
|
||||
|
||||
To reset your password, go to <https://www.npmjs.com/forgot>
|
||||
|
||||
To change your email address, go to <https://www.npmjs.com/email-edit>
|
||||
|
||||
You may use this command multiple times with the same user account to
|
||||
authorize on a new machine. When authenticating on a new machine,
|
||||
the username, password and email address must all match with
|
||||
your existing record.
|
||||
|
||||
`npm login` is an alias to `adduser` and behaves exactly the same way.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### registry
|
||||
|
||||
Default: https://registry.npmjs.org/
|
||||
|
||||
The base URL of the npm package registry. If `scope` is also specified,
|
||||
this registry will only be used for packages with that scope. `scope` defaults
|
||||
to the scope of the project directory you're currently in, if any. See `npm-scope(7)`.
|
||||
|
||||
### scope
|
||||
|
||||
Default: none
|
||||
|
||||
If specified, the user and login credentials given will be associated
|
||||
with the specified scope. See `npm-scope(7)`. You can use both at the same time,
|
||||
e.g.
|
||||
|
||||
npm adduser --registry=http://myregistry.example.com --scope=@myco
|
||||
|
||||
This will set a registry for the given scope and login or create a user for
|
||||
that registry at the same time.
|
||||
|
||||
### always-auth
|
||||
|
||||
Default: false
|
||||
|
||||
If specified, save configuration indicating that all requests to the given
|
||||
registry should include authorization information. Useful for private
|
||||
registries. Can be used with `--registry` and / or `--scope`, e.g.
|
||||
|
||||
npm adduser --registry=http://private-registry.example.com --always-auth
|
||||
|
||||
This will ensure that all requests to that registry (including for tarballs)
|
||||
include an authorization header. This setting may be necessary for use with
|
||||
private registries where metadata and package tarballs are stored on hosts with
|
||||
different hostnames. See `always-auth` in `npm-config(7)` for more details on
|
||||
always-auth. Registry-specific configuration of `always-auth` takes precedence
|
||||
over any global configuration.
|
||||
|
||||
### auth-type
|
||||
|
||||
* Default: `'legacy'`
|
||||
* Type: `'legacy'`, `'sso'`, `'saml'`, `'oauth'`
|
||||
|
||||
What authentication strategy to use with `adduser`/`login`. Some npm registries
|
||||
(for example, npmE) might support alternative auth strategies besides classic
|
||||
username/password entry in legacy npm.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-registry(7)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* npm-owner(1)
|
||||
* npm-whoami(1)
|
||||
106
website/node_modules/npm/doc/cli/npm-audit.md
generated
vendored
Normal file
106
website/node_modules/npm/doc/cli/npm-audit.md
generated
vendored
Normal file
@@ -0,0 +1,106 @@
|
||||
npm-audit(1) -- Run a security audit
|
||||
====================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm audit [--json|--parseable]
|
||||
npm audit fix [--force|--package-lock-only|--dry-run|--production|--only=dev]
|
||||
|
||||
## EXAMPLES
|
||||
|
||||
Scan your project for vulnerabilities and automatically install any compatible
|
||||
updates to vulnerable dependencies:
|
||||
```
|
||||
$ npm audit fix
|
||||
```
|
||||
|
||||
Run `audit fix` without modifying `node_modules`, but still updating the
|
||||
pkglock:
|
||||
```
|
||||
$ npm audit fix --package-lock-only
|
||||
```
|
||||
|
||||
Skip updating `devDependencies`:
|
||||
```
|
||||
$ npm audit fix --only=prod
|
||||
```
|
||||
|
||||
Have `audit fix` install semver-major updates to toplevel dependencies, not just
|
||||
semver-compatible ones:
|
||||
```
|
||||
$ npm audit fix --force
|
||||
```
|
||||
|
||||
Do a dry run to get an idea of what `audit fix` will do, and _also_ output
|
||||
install information in JSON format:
|
||||
```
|
||||
$ npm audit fix --dry-run --json
|
||||
```
|
||||
|
||||
Scan your project for vulnerabilities and just show the details, without fixing
|
||||
anything:
|
||||
```
|
||||
$ npm audit
|
||||
```
|
||||
|
||||
Get the detailed audit report in JSON format:
|
||||
```
|
||||
$ npm audit --json
|
||||
```
|
||||
|
||||
Get the detailed audit report in plain text result, separated by tab characters, allowing for
|
||||
future reuse in scripting or command line post processing, like for example, selecting
|
||||
some of the columns printed:
|
||||
```
|
||||
$ npm audit --parseable
|
||||
```
|
||||
|
||||
To parse columns, you can use for example `awk`, and just print some of them:
|
||||
```
|
||||
$ npm audit --parseable | awk -F $'\t' '{print $1,$4}'
|
||||
```
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
The audit command submits a description of the dependencies configured in
|
||||
your project to your default registry and asks for a report of known
|
||||
vulnerabilities. The report returned includes instructions on how to act on
|
||||
this information.
|
||||
|
||||
You can also have npm automatically fix the vulnerabilities by running `npm
|
||||
audit fix`. Note that some vulnerabilities cannot be fixed automatically and
|
||||
will require manual intervention or review. Also note that since `npm audit fix`
|
||||
runs a full-fledged `npm install` under the hood, all configs that apply to the
|
||||
installer will also apply to `npm install` -- so things like `npm audit fix
|
||||
--package-lock-only` will work as expected.
|
||||
|
||||
## CONTENT SUBMITTED
|
||||
|
||||
* npm_version
|
||||
* node_version
|
||||
* platform
|
||||
* node_env
|
||||
* A scrubbed version of your package-lock.json or npm-shrinkwrap.json
|
||||
|
||||
### SCRUBBING
|
||||
|
||||
In order to ensure that potentially sensitive information is not included in
|
||||
the audit data bundle, some dependencies may have their names (and sometimes
|
||||
versions) replaced with opaque non-reversible identifiers. It is done for
|
||||
the following dependency types:
|
||||
|
||||
* Any module referencing a scope that is configured for a non-default
|
||||
registry has its name scrubbed. (That is, a scope you did a `npm login --scope=@ourscope` for.)
|
||||
* All git dependencies have their names and specifiers scrubbed.
|
||||
* All remote tarball dependencies have their names and specifiers scrubbed.
|
||||
* All local directory and tarball dependencies have their names and specifiers scrubbed.
|
||||
|
||||
The non-reversible identifiers are a sha256 of a session-specific UUID and the
|
||||
value being replaced, ensuring a consistent value within the payload that is
|
||||
different between runs.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-install(1)
|
||||
* package-locks(5)
|
||||
* config(7)
|
||||
19
website/node_modules/npm/doc/cli/npm-bin.md
generated
vendored
Normal file
19
website/node_modules/npm/doc/cli/npm-bin.md
generated
vendored
Normal file
@@ -0,0 +1,19 @@
|
||||
npm-bin(1) -- Display npm bin folder
|
||||
====================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm bin [-g|--global]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Print the folder where npm will install executables.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-prefix(1)
|
||||
* npm-root(1)
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
43
website/node_modules/npm/doc/cli/npm-bugs.md
generated
vendored
Normal file
43
website/node_modules/npm/doc/cli/npm-bugs.md
generated
vendored
Normal file
@@ -0,0 +1,43 @@
|
||||
npm-bugs(1) -- Bugs for a package in a web browser maybe
|
||||
========================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm bugs [<pkgname>]
|
||||
|
||||
aliases: issues
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command tries to guess at the likely location of a package's
|
||||
bug tracker URL, and then tries to open it using the `--browser`
|
||||
config param. If no package name is provided, it will search for
|
||||
a `package.json` in the current folder and use the `name` property.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### browser
|
||||
|
||||
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
|
||||
* Type: String
|
||||
|
||||
The browser that is called by the `npm bugs` command to open websites.
|
||||
|
||||
### registry
|
||||
|
||||
* Default: https://registry.npmjs.org/
|
||||
* Type: url
|
||||
|
||||
The base URL of the npm package registry.
|
||||
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-docs(1)
|
||||
* npm-view(1)
|
||||
* npm-publish(1)
|
||||
* npm-registry(7)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* package.json(5)
|
||||
25
website/node_modules/npm/doc/cli/npm-build.md
generated
vendored
Normal file
25
website/node_modules/npm/doc/cli/npm-build.md
generated
vendored
Normal file
@@ -0,0 +1,25 @@
|
||||
npm-build(1) -- Build a package
|
||||
===============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm build [<package-folder>]
|
||||
|
||||
* `<package-folder>`:
|
||||
A folder containing a `package.json` file in its root.
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This is the plumbing command called by `npm link` and `npm install`.
|
||||
|
||||
It should generally be called during installation, but if you need to run it
|
||||
directly, run:
|
||||
|
||||
npm run-script build
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-install(1)
|
||||
* npm-link(1)
|
||||
* npm-scripts(7)
|
||||
* package.json(5)
|
||||
14
website/node_modules/npm/doc/cli/npm-bundle.md
generated
vendored
Normal file
14
website/node_modules/npm/doc/cli/npm-bundle.md
generated
vendored
Normal file
@@ -0,0 +1,14 @@
|
||||
npm-bundle(1) -- REMOVED
|
||||
========================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
The `npm bundle` command has been removed in 1.0, for the simple reason
|
||||
that it is no longer necessary, as the default behavior is now to
|
||||
install packages into the local space.
|
||||
|
||||
Just use `npm install` now to do what `npm bundle` used to do.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-install(1)
|
||||
83
website/node_modules/npm/doc/cli/npm-cache.md
generated
vendored
Normal file
83
website/node_modules/npm/doc/cli/npm-cache.md
generated
vendored
Normal file
@@ -0,0 +1,83 @@
|
||||
npm-cache(1) -- Manipulates packages cache
|
||||
==========================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm cache add <tarball file>
|
||||
npm cache add <folder>
|
||||
npm cache add <tarball url>
|
||||
npm cache add <name>@<version>
|
||||
|
||||
npm cache clean [<path>]
|
||||
aliases: npm cache clear, npm cache rm
|
||||
|
||||
npm cache verify
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Used to add, list, or clean the npm cache folder.
|
||||
|
||||
* add:
|
||||
Add the specified package to the local cache. This command is primarily
|
||||
intended to be used internally by npm, but it can provide a way to
|
||||
add data to the local installation cache explicitly.
|
||||
|
||||
* clean:
|
||||
Delete all data out of the cache folder.
|
||||
|
||||
* verify:
|
||||
Verify the contents of the cache folder, garbage collecting any unneeded data,
|
||||
and verifying the integrity of the cache index and all cached data.
|
||||
|
||||
## DETAILS
|
||||
|
||||
npm stores cache data in an opaque directory within the configured `cache`,
|
||||
named `_cacache`. This directory is a `cacache`-based content-addressable cache
|
||||
that stores all http request data as well as other package-related data. This
|
||||
directory is primarily accessed through `pacote`, the library responsible for
|
||||
all package fetching as of npm@5.
|
||||
|
||||
All data that passes through the cache is fully verified for integrity on both
|
||||
insertion and extraction. Cache corruption will either trigger an error, or
|
||||
signal to `pacote` that the data must be refetched, which it will do
|
||||
automatically. For this reason, it should never be necessary to clear the cache
|
||||
for any reason other than reclaiming disk space, thus why `clean` now requires
|
||||
`--force` to run.
|
||||
|
||||
There is currently no method exposed through npm to inspect or directly manage
|
||||
the contents of this cache. In order to access it, `cacache` must be used
|
||||
directly.
|
||||
|
||||
npm will not remove data by itself: the cache will grow as new packages are
|
||||
installed.
|
||||
|
||||
## A NOTE ABOUT THE CACHE'S DESIGN
|
||||
|
||||
The npm cache is strictly a cache: it should not be relied upon as a persistent
|
||||
and reliable data store for package data. npm makes no guarantee that a
|
||||
previously-cached piece of data will be available later, and will automatically
|
||||
delete corrupted contents. The primary guarantee that the cache makes is that,
|
||||
if it does return data, that data will be exactly the data that was inserted.
|
||||
|
||||
To run an offline verification of existing cache contents, use `npm cache
|
||||
verify`.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### cache
|
||||
|
||||
Default: `~/.npm` on Posix, or `%AppData%/npm-cache` on Windows.
|
||||
|
||||
The root cache folder.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* npm-install(1)
|
||||
* npm-publish(1)
|
||||
* npm-pack(1)
|
||||
* https://npm.im/cacache
|
||||
* https://npm.im/pacote
|
||||
59
website/node_modules/npm/doc/cli/npm-ci.md
generated
vendored
Normal file
59
website/node_modules/npm/doc/cli/npm-ci.md
generated
vendored
Normal file
@@ -0,0 +1,59 @@
|
||||
npm-ci(1) -- Install a project with a clean slate
|
||||
===================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm ci
|
||||
|
||||
## EXAMPLE
|
||||
|
||||
Make sure you have a package-lock and an up-to-date install:
|
||||
|
||||
```
|
||||
$ cd ./my/npm/project
|
||||
$ npm install
|
||||
added 154 packages in 10s
|
||||
$ ls | grep package-lock
|
||||
```
|
||||
|
||||
Run `npm ci` in that project
|
||||
|
||||
```
|
||||
$ npm ci
|
||||
added 154 packages in 5s
|
||||
```
|
||||
|
||||
Configure Travis to build using `npm ci` instead of `npm install`:
|
||||
|
||||
```
|
||||
# .travis.yml
|
||||
install:
|
||||
- npm ci
|
||||
# keep the npm cache around to speed up installs
|
||||
cache:
|
||||
directories:
|
||||
- "$HOME/.npm"
|
||||
```
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command is similar to `npm-install(1)`, except it's meant to be used in
|
||||
automated environments such as test platforms, continuous integration, and
|
||||
deployment -- or any situation where you want to make sure you're doing a clean
|
||||
install of your dependencies. It can be significantly faster than a regular npm
|
||||
install by skipping certain user-oriented features. It is also more strict than
|
||||
a regular install, which can help catch errors or inconsistencies caused by the
|
||||
incrementally-installed local environments of most npm users.
|
||||
|
||||
In short, the main differences between using `npm install` and `npm ci` are:
|
||||
|
||||
* The project **must** have an existing `package-lock.json` or `npm-shrinkwrap.json`.
|
||||
* If dependencies in the package lock do not match those in `package.json`, `npm ci` will exit with an error, instead of updating the package lock.
|
||||
* `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
|
||||
* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
|
||||
* It will never write to `package.json` or any of the package-locks: installs are essentially frozen.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-install(1)
|
||||
* npm-package-locks(5)
|
||||
32
website/node_modules/npm/doc/cli/npm-completion.md
generated
vendored
Normal file
32
website/node_modules/npm/doc/cli/npm-completion.md
generated
vendored
Normal file
@@ -0,0 +1,32 @@
|
||||
npm-completion(1) -- Tab Completion for npm
|
||||
===========================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
source <(npm completion)
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Enables tab-completion in all npm commands.
|
||||
|
||||
The synopsis above
|
||||
loads the completions into your current shell. Adding it to
|
||||
your ~/.bashrc or ~/.zshrc will make the completions available
|
||||
everywhere:
|
||||
|
||||
npm completion >> ~/.bashrc
|
||||
npm completion >> ~/.zshrc
|
||||
|
||||
You may of course also pipe the output of `npm completion` to a file
|
||||
such as `/usr/local/etc/bash_completion.d/npm` or
|
||||
`/etc/bash_completion.d/npm` if you have a system that will read
|
||||
that file for you.
|
||||
|
||||
When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the
|
||||
environment, `npm completion` acts in "plumbing mode", and outputs
|
||||
completions based on the arguments.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-developers(7)
|
||||
* npm(1)
|
||||
73
website/node_modules/npm/doc/cli/npm-config.md
generated
vendored
Normal file
73
website/node_modules/npm/doc/cli/npm-config.md
generated
vendored
Normal file
@@ -0,0 +1,73 @@
|
||||
npm-config(1) -- Manage the npm configuration files
|
||||
===================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm config set <key> <value> [-g|--global]
|
||||
npm config get <key>
|
||||
npm config delete <key>
|
||||
npm config list [-l] [--json]
|
||||
npm config edit
|
||||
npm get <key>
|
||||
npm set <key> <value> [-g|--global]
|
||||
|
||||
aliases: c
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
npm gets its config settings from the command line, environment
|
||||
variables, `npmrc` files, and in some cases, the `package.json` file.
|
||||
|
||||
See npmrc(5) for more information about the npmrc files.
|
||||
|
||||
See `npm-config(7)` for a more thorough discussion of the mechanisms
|
||||
involved.
|
||||
|
||||
The `npm config` command can be used to update and edit the contents
|
||||
of the user and global npmrc files.
|
||||
|
||||
## Sub-commands
|
||||
|
||||
Config supports the following sub-commands:
|
||||
|
||||
### set
|
||||
|
||||
npm config set key value
|
||||
|
||||
Sets the config key to the value.
|
||||
|
||||
If value is omitted, then it sets it to "true".
|
||||
|
||||
### get
|
||||
|
||||
npm config get key
|
||||
|
||||
Echo the config value to stdout.
|
||||
|
||||
### list
|
||||
|
||||
npm config list
|
||||
|
||||
Show all the config settings. Use `-l` to also show defaults. Use `--json`
|
||||
to show the settings in json format.
|
||||
|
||||
### delete
|
||||
|
||||
npm config delete key
|
||||
|
||||
Deletes the key from all configuration files.
|
||||
|
||||
### edit
|
||||
|
||||
npm config edit
|
||||
|
||||
Opens the config file in an editor. Use the `--global` flag to edit the
|
||||
global config.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-folders(5)
|
||||
* npm-config(7)
|
||||
* package.json(5)
|
||||
* npmrc(5)
|
||||
* npm(1)
|
||||
55
website/node_modules/npm/doc/cli/npm-dedupe.md
generated
vendored
Normal file
55
website/node_modules/npm/doc/cli/npm-dedupe.md
generated
vendored
Normal file
@@ -0,0 +1,55 @@
|
||||
npm-dedupe(1) -- Reduce duplication
|
||||
===================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm dedupe
|
||||
npm ddp
|
||||
|
||||
aliases: find-dupes, ddp
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Searches the local package tree and attempts to simplify the overall
|
||||
structure by moving dependencies further up the tree, where they can
|
||||
be more effectively shared by multiple dependent packages.
|
||||
|
||||
For example, consider this dependency graph:
|
||||
|
||||
a
|
||||
+-- b <-- depends on c@1.0.x
|
||||
| `-- c@1.0.3
|
||||
`-- d <-- depends on c@~1.0.9
|
||||
`-- c@1.0.10
|
||||
|
||||
In this case, `npm-dedupe(1)` will transform the tree to:
|
||||
|
||||
a
|
||||
+-- b
|
||||
+-- d
|
||||
`-- c@1.0.10
|
||||
|
||||
Because of the hierarchical nature of node's module lookup, b and d
|
||||
will both get their dependency met by the single c package at the root
|
||||
level of the tree.
|
||||
|
||||
The deduplication algorithm walks the tree, moving each dependency as far
|
||||
up in the tree as possible, even if duplicates are not found. This will
|
||||
result in both a flat and deduplicated tree.
|
||||
|
||||
If a suitable version exists at the target location in the tree
|
||||
already, then it will be left untouched, but the other duplicates will
|
||||
be deleted.
|
||||
|
||||
Arguments are ignored. Dedupe always acts on the entire tree.
|
||||
|
||||
Modules
|
||||
|
||||
Note that this operation transforms the dependency tree, but will never
|
||||
result in new modules being installed.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-ls(1)
|
||||
* npm-update(1)
|
||||
* npm-install(1)
|
||||
28
website/node_modules/npm/doc/cli/npm-deprecate.md
generated
vendored
Normal file
28
website/node_modules/npm/doc/cli/npm-deprecate.md
generated
vendored
Normal file
@@ -0,0 +1,28 @@
|
||||
npm-deprecate(1) -- Deprecate a version of a package
|
||||
====================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm deprecate <pkg>[@<version>] <message>
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command will update the npm registry entry for a package, providing
|
||||
a deprecation warning to all who attempt to install it.
|
||||
|
||||
It works on [version ranges](https://semver.npmjs.com/) as well as specific
|
||||
versions, so you can do something like this:
|
||||
|
||||
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
|
||||
|
||||
Note that you must be the package owner to deprecate something. See the
|
||||
`owner` and `adduser` help topics.
|
||||
|
||||
To un-deprecate a package, specify an empty string (`""`) for the `message`
|
||||
argument. Note that you must use double quotes with no space between them to
|
||||
format an empty string.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-publish(1)
|
||||
* npm-registry(7)
|
||||
88
website/node_modules/npm/doc/cli/npm-dist-tag.md
generated
vendored
Normal file
88
website/node_modules/npm/doc/cli/npm-dist-tag.md
generated
vendored
Normal file
@@ -0,0 +1,88 @@
|
||||
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. If you have two-factor authentication on
|
||||
auth-and-writes then you’ll need to include a one-time password on the
|
||||
command line with `--otp <one-time password>`.
|
||||
|
||||
* 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-publish(1)
|
||||
* npm-install(1)
|
||||
* npm-dedupe(1)
|
||||
* npm-registry(7)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
44
website/node_modules/npm/doc/cli/npm-docs.md
generated
vendored
Normal file
44
website/node_modules/npm/doc/cli/npm-docs.md
generated
vendored
Normal file
@@ -0,0 +1,44 @@
|
||||
npm-docs(1) -- Docs for a package in a web browser maybe
|
||||
========================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm docs [<pkgname> [<pkgname> ...]]
|
||||
npm docs .
|
||||
npm home [<pkgname> [<pkgname> ...]]
|
||||
npm home .
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command tries to guess at the likely location of a package's
|
||||
documentation URL, and then tries to open it using the `--browser`
|
||||
config param. You can pass multiple package names at once. If no
|
||||
package name is provided, it will search for a `package.json` in
|
||||
the current folder and use the `name` property.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### browser
|
||||
|
||||
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
|
||||
* Type: String
|
||||
|
||||
The browser that is called by the `npm docs` command to open websites.
|
||||
|
||||
### registry
|
||||
|
||||
* Default: https://registry.npmjs.org/
|
||||
* Type: url
|
||||
|
||||
The base URL of the npm package registry.
|
||||
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-view(1)
|
||||
* npm-publish(1)
|
||||
* npm-registry(7)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* package.json(5)
|
||||
102
website/node_modules/npm/doc/cli/npm-doctor.md
generated
vendored
Normal file
102
website/node_modules/npm/doc/cli/npm-doctor.md
generated
vendored
Normal file
@@ -0,0 +1,102 @@
|
||||
npm-doctor(1) -- Check your environments
|
||||
========================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm doctor
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
`npm doctor` runs a set of checks to ensure that your npm installation has
|
||||
what it needs to manage your JavaScript packages. npm is mostly a standalone tool, but it does
|
||||
have some basic requirements that must be met:
|
||||
|
||||
+ Node.js and git must be executable by npm.
|
||||
+ The primary npm registry, `registry.npmjs.com`, or another service that uses
|
||||
the registry API, is available.
|
||||
+ The directories that npm uses, `node_modules` (both locally and globally),
|
||||
exist and can be written by the current user.
|
||||
+ The npm cache exists, and the package tarballs within it aren't corrupt.
|
||||
|
||||
Without all of these working properly, npm may not work properly. Many issues
|
||||
are often attributable to things that are outside npm's code base, so `npm
|
||||
doctor` confirms that the npm installation is in a good state.
|
||||
|
||||
Also, in addition to this, there are also very many issue reports due to using
|
||||
old versions of npm. Since npm is constantly improving, running `npm@latest` is
|
||||
better than an old version.
|
||||
|
||||
`npm doctor` verifies the following items in your environment, and if there are
|
||||
any recommended changes, it will display them.
|
||||
|
||||
### `npm ping`
|
||||
|
||||
By default, npm installs from the primary npm registry, `registry.npmjs.org`.
|
||||
`npm doctor` hits a special ping endpoint within the registry. This can also be
|
||||
checked with `npm ping`. If this check fails, you may be using a proxy that
|
||||
needs to be configured, or may need to talk to your IT staff to get access over
|
||||
HTTPS to `registry.npmjs.org`.
|
||||
|
||||
This check is done against whichever registry you've configured (you can see
|
||||
what that is by running `npm config get registry`), and if you're using a
|
||||
private registry that doesn't support the `/whoami` endpoint supported by the
|
||||
primary registry, this check may fail.
|
||||
|
||||
### `npm -v`
|
||||
|
||||
While Node.js may come bundled with a particular version of npm, it's the
|
||||
policy of the CLI team that we recommend all users run `npm@latest` if they
|
||||
can. As the CLI is maintained by a small team of contributors, there are only
|
||||
resources for a single line of development, so npm's own long-term support
|
||||
releases typically only receive critical security and regression fixes. The
|
||||
team believes that the latest tested version of npm is almost always likely to
|
||||
be the most functional and defect-free version of npm.
|
||||
|
||||
### `node -v`
|
||||
|
||||
For most users, in most circumstances, the best version of Node will be the
|
||||
latest long-term support (LTS) release. Those of you who want access to new
|
||||
ECMAscript features or bleeding-edge changes to Node's standard library may be
|
||||
running a newer version, and some of you may be required to run an older
|
||||
version of Node because of enterprise change control policies. That's OK! But
|
||||
in general, the npm team recommends that most users run Node.js LTS.
|
||||
|
||||
### `npm config get registry`
|
||||
|
||||
Some of you may be installing from private package registries for your project
|
||||
or company. That's great! Others of you may be following tutorials or
|
||||
StackOverflow questions in an effort to troubleshoot problems you may be
|
||||
having. Sometimes, this may entail changing the registry you're pointing at.
|
||||
This part of `npm doctor` just lets you, and maybe whoever's helping you with
|
||||
support, know that you're not using the default registry.
|
||||
|
||||
### `which git`
|
||||
|
||||
While it's documented in the README, it may not be obvious that npm needs Git
|
||||
installed to do many of the things that it does. Also, in some cases
|
||||
– especially on Windows – you may have Git set up in such a way that it's not
|
||||
accessible via your `PATH` so that npm can find it. This check ensures that Git
|
||||
is available.
|
||||
|
||||
### Permissions checks
|
||||
|
||||
* Your cache must be readable and writable by the user running npm.
|
||||
* Global package binaries must be writable by the user running npm.
|
||||
* Your local `node_modules` path, if you're running `npm doctor` with a project
|
||||
directory, must be readable and writable by the user running npm.
|
||||
|
||||
### Validate the checksums of cached packages
|
||||
|
||||
When an npm package is published, the publishing process generates a checksum
|
||||
that npm uses at install time to verify that the package didn't get corrupted
|
||||
in transit. `npm doctor` uses these checksums to validate the package tarballs
|
||||
in your local cache (you can see where that cache is located with `npm config
|
||||
get cache`, and see what's in that cache with `npm cache ls` – probably more
|
||||
than you were expecting!). In the event that there are corrupt packages in your
|
||||
cache, you should probably run `npm cache clean` and reset the cache.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-bugs(1)
|
||||
* npm-help(1)
|
||||
* npm-ping(1)
|
||||
39
website/node_modules/npm/doc/cli/npm-edit.md
generated
vendored
Normal file
39
website/node_modules/npm/doc/cli/npm-edit.md
generated
vendored
Normal file
@@ -0,0 +1,39 @@
|
||||
npm-edit(1) -- Edit an installed package
|
||||
========================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm edit <pkg>[/<subpkg>...]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Selects a (sub)dependency in the current
|
||||
working directory and opens the package folder in the default editor
|
||||
(or whatever you've configured as the npm `editor` config -- see
|
||||
`npm-config(7)`.)
|
||||
|
||||
After it has been edited, the package is rebuilt so as to pick up any
|
||||
changes in compiled packages.
|
||||
|
||||
For instance, you can do `npm install connect` to install connect
|
||||
into your package, and then `npm edit connect` to make a few
|
||||
changes to your locally installed copy.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### editor
|
||||
|
||||
* Default: `EDITOR` environment variable if set, or `"vi"` on Posix,
|
||||
or `"notepad"` on Windows.
|
||||
* Type: path
|
||||
|
||||
The command to run for `npm edit` or `npm config edit`.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-folders(5)
|
||||
* npm-explore(1)
|
||||
* npm-install(1)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
39
website/node_modules/npm/doc/cli/npm-explore.md
generated
vendored
Normal file
39
website/node_modules/npm/doc/cli/npm-explore.md
generated
vendored
Normal file
@@ -0,0 +1,39 @@
|
||||
npm-explore(1) -- Browse an installed package
|
||||
=============================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm explore <pkg> [ -- <command>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Spawn a subshell in the directory of the installed package specified.
|
||||
|
||||
If a command is specified, then it is run in the subshell, which then
|
||||
immediately terminates.
|
||||
|
||||
This is particularly handy in the case of git submodules in the
|
||||
`node_modules` folder:
|
||||
|
||||
npm explore some-dependency -- git pull origin master
|
||||
|
||||
Note that the package is *not* automatically rebuilt afterwards, so be
|
||||
sure to use `npm rebuild <pkg>` if you make any changes.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### shell
|
||||
|
||||
* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
|
||||
Windows
|
||||
* Type: path
|
||||
|
||||
The shell to run for the `npm explore` command.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-folders(5)
|
||||
* npm-edit(1)
|
||||
* npm-rebuild(1)
|
||||
* npm-build(1)
|
||||
* npm-install(1)
|
||||
34
website/node_modules/npm/doc/cli/npm-help-search.md
generated
vendored
Normal file
34
website/node_modules/npm/doc/cli/npm-help-search.md
generated
vendored
Normal file
@@ -0,0 +1,34 @@
|
||||
npm-help-search(1) -- Search npm help documentation
|
||||
===================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm help-search <text>
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command will search the npm markdown documentation files for the
|
||||
terms provided, and then list the results, sorted by relevance.
|
||||
|
||||
If only one result is found, then it will show that help topic.
|
||||
|
||||
If the argument to `npm help` is not a known help topic, then it will
|
||||
call `help-search`. It is rarely if ever necessary to call this
|
||||
command directly.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### long
|
||||
|
||||
* Type: Boolean
|
||||
* Default: false
|
||||
|
||||
If true, the "long" flag will cause help-search to output context around
|
||||
where the terms were found in the documentation.
|
||||
|
||||
If false, then help-search will just list out the help topics found.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm(1)
|
||||
* npm-help(1)
|
||||
38
website/node_modules/npm/doc/cli/npm-help.md
generated
vendored
Normal file
38
website/node_modules/npm/doc/cli/npm-help.md
generated
vendored
Normal file
@@ -0,0 +1,38 @@
|
||||
npm-help(1) -- Get help on npm
|
||||
==============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm help <term> [<terms..>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
If supplied a topic, then show the appropriate documentation page.
|
||||
|
||||
If the topic does not exist, or if multiple terms are provided, then run
|
||||
the `help-search` command to find a match. Note that, if `help-search`
|
||||
finds a single subject, then it will run `help` on that topic, so unique
|
||||
matches are equivalent to specifying a topic name.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### viewer
|
||||
|
||||
* Default: "man" on Posix, "browser" on Windows
|
||||
* Type: path
|
||||
|
||||
The program to use to view help content.
|
||||
|
||||
Set to `"browser"` to view html help content in the default web browser.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm(1)
|
||||
* README
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* package.json(5)
|
||||
* npm-help-search(1)
|
||||
* npm-index(7)
|
||||
72
website/node_modules/npm/doc/cli/npm-hook.md
generated
vendored
Normal file
72
website/node_modules/npm/doc/cli/npm-hook.md
generated
vendored
Normal file
@@ -0,0 +1,72 @@
|
||||
npm-hook(1) -- Manage registry hooks
|
||||
===================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm hook ls [pkg]
|
||||
npm hook add <entity> <url> <secret>
|
||||
npm hook update <id> <url> [secret]
|
||||
npm hook rm <id>
|
||||
|
||||
## EXAMPLE
|
||||
|
||||
Add a hook to watch a package for changes:
|
||||
```
|
||||
$ npm hook add lodash https://example.com/ my-shared-secret
|
||||
```
|
||||
|
||||
Add a hook to watch packages belonging to the user `substack`:
|
||||
```
|
||||
$ npm hook add ~substack https://example.com/ my-shared-secret
|
||||
```
|
||||
|
||||
Add a hook to watch packages in the scope `@npm`
|
||||
```
|
||||
$ npm hook add @npm https://example.com/ my-shared-secret
|
||||
```
|
||||
|
||||
List all your active hooks:
|
||||
```
|
||||
$ npm hook ls
|
||||
```
|
||||
|
||||
List your active hooks for the `lodash` package:
|
||||
```
|
||||
$ npm hook ls lodash
|
||||
```
|
||||
|
||||
Update an existing hook's url:
|
||||
```
|
||||
$ npm hook update id-deadbeef https://my-new-website.here/
|
||||
```
|
||||
|
||||
Remove a hook:
|
||||
```
|
||||
$ npm hook rm id-deadbeef
|
||||
```
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Allows you to manage [npm
|
||||
hooks](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm),
|
||||
including adding, removing, listing, and updating.
|
||||
|
||||
Hooks allow you to configure URL endpoints that will be notified whenever a
|
||||
change happens to any of the supported entity types. Three different types of
|
||||
entities can be watched by hooks: packages, owners, and scopes.
|
||||
|
||||
To create a package hook, simply reference the package name.
|
||||
|
||||
To create an owner hook, prefix the owner name with `~` (as in, `~youruser`).
|
||||
|
||||
To create a scope hook, prefix the scope name with `@` (as in, `@yourscope`).
|
||||
|
||||
The hook `id` used by `update` and `rm` are the IDs listed in `npm hook ls` for
|
||||
that particular hook.
|
||||
|
||||
The shared secret will be sent along to the URL endpoint so you can verify the
|
||||
request came from your own configured hook.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* ["Introducing Hooks" blog post](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm)
|
||||
66
website/node_modules/npm/doc/cli/npm-init.md
generated
vendored
Normal file
66
website/node_modules/npm/doc/cli/npm-init.md
generated
vendored
Normal file
@@ -0,0 +1,66 @@
|
||||
npm-init(1) -- create a package.json file
|
||||
=======================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm init [--force|-f|--yes|-y|--scope]
|
||||
npm init <@scope> (same as `npx <@scope>/create`)
|
||||
npm init [<@scope>/]<name> (same as `npx [<@scope>/]create-<name>`)
|
||||
|
||||
## EXAMPLES
|
||||
|
||||
Create a new React-based project using [`create-react-app`](https://npm.im/create-react-app):
|
||||
```
|
||||
$ npm init react-app ./my-react-app
|
||||
```
|
||||
|
||||
Create a new `esm`-compatible package using [`create-esm`](https://npm.im/create-esm):
|
||||
```
|
||||
$ mkdir my-esm-lib && cd my-esm-lib
|
||||
$ npm init esm --yes
|
||||
```
|
||||
|
||||
Generate a plain old package.json using legacy init:
|
||||
```
|
||||
$ mkdir my-npm-pkg && cd my-npm-pkg
|
||||
$ git init
|
||||
$ npm init
|
||||
```
|
||||
|
||||
Generate it without having it ask any questions:
|
||||
```
|
||||
$ npm init -y
|
||||
```
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
`npm init <initializer>` can be used to set up a new or existing npm package.
|
||||
|
||||
`initializer` in this case is an npm package named `create-<initializer>`, which
|
||||
will be installed by [`npx(1)`](https://npm.im/npx), and then have its main bin
|
||||
executed -- presumably creating or updating `package.json` and running any other
|
||||
initialization-related operations.
|
||||
|
||||
The init command is transformed to a corresponding `npx` operation as follows:
|
||||
|
||||
* `npm init foo` -> `npx create-foo`
|
||||
* `npm init @usr/foo` -> `npx @usr/create-foo`
|
||||
* `npm init @usr` -> `npx @usr/create`
|
||||
|
||||
Any additional options will be passed directly to the command, so `npm init foo
|
||||
--hello` will map to `npx create-foo --hello`.
|
||||
|
||||
If the initializer is omitted (by just calling `npm init`), init will fall back
|
||||
to legacy init behavior. It will ask you a bunch of questions, and then write a
|
||||
package.json for you. It will attempt to make reasonable guesses based on
|
||||
existing fields, dependencies, and options selected. It is strictly additive, so
|
||||
it will keep any fields and values that were already set. You can also use
|
||||
`-y`/`--yes` to skip the questionnaire altogether. If you pass `--scope`, it
|
||||
will create a scoped package.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* <https://github.com/isaacs/init-package-json>
|
||||
* package.json(5)
|
||||
* npm-version(1)
|
||||
* npm-scope(7)
|
||||
16
website/node_modules/npm/doc/cli/npm-install-ci-test.md
generated
vendored
Normal file
16
website/node_modules/npm/doc/cli/npm-install-ci-test.md
generated
vendored
Normal file
@@ -0,0 +1,16 @@
|
||||
# npm install-ci-test(1) -- Install a project with a clean slate and run tests
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm install-ci-test
|
||||
|
||||
alias: npm cit
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command runs an `npm ci` followed immediately by an `npm test`.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
- npm-ci(1)
|
||||
- npm-test(1)
|
||||
25
website/node_modules/npm/doc/cli/npm-install-test.md
generated
vendored
Normal file
25
website/node_modules/npm/doc/cli/npm-install-test.md
generated
vendored
Normal file
@@ -0,0 +1,25 @@
|
||||
# npm install-test(1) -- Install package(s) and run tests
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm install-test (with no args, in package dir)
|
||||
npm install-test [<@scope>/]<name>
|
||||
npm install-test [<@scope>/]<name>@<tag>
|
||||
npm install-test [<@scope>/]<name>@<version>
|
||||
npm install-test [<@scope>/]<name>@<version range>
|
||||
npm install-test <tarball file>
|
||||
npm install-test <tarball url>
|
||||
npm install-test <folder>
|
||||
|
||||
alias: npm it
|
||||
common options: [--save|--save-dev|--save-optional] [--save-exact] [--dry-run]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command runs an `npm install` followed immediately by an `npm test`. It
|
||||
takes exactly the same arguments as `npm install`.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
- npm-install(1)
|
||||
- npm-test(1)
|
||||
457
website/node_modules/npm/doc/cli/npm-install.md
generated
vendored
Normal file
457
website/node_modules/npm/doc/cli/npm-install.md
generated
vendored
Normal file
@@ -0,0 +1,457 @@
|
||||
npm-install(1) -- Install a package
|
||||
===================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm install (with no args, in package dir)
|
||||
npm install [<@scope>/]<name>
|
||||
npm install [<@scope>/]<name>@<tag>
|
||||
npm install [<@scope>/]<name>@<version>
|
||||
npm install [<@scope>/]<name>@<version range>
|
||||
npm install <git-host>:<git-user>/<repo-name>
|
||||
npm install <git repo url>
|
||||
npm install <tarball file>
|
||||
npm install <tarball url>
|
||||
npm install <folder>
|
||||
|
||||
alias: npm i
|
||||
common options: [-P|--save-prod|-D|--save-dev|-O|--save-optional] [-E|--save-exact] [-B|--save-bundle] [--no-save] [--dry-run]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command installs a package, and any packages that it depends on. If the
|
||||
package has a package-lock or shrinkwrap file, the installation of dependencies
|
||||
will be driven by that, with an `npm-shrinkwrap.json` taking precedence if both
|
||||
files exist. See package-lock.json(5) and npm-shrinkwrap(1).
|
||||
|
||||
A `package` is:
|
||||
|
||||
* a) a folder containing a program described by a `package.json(5)` file
|
||||
* b) a gzipped tarball containing (a)
|
||||
* c) a url that resolves to (b)
|
||||
* d) a `<name>@<version>` that is published on the registry (see `npm-registry(7)`) with (c)
|
||||
* e) a `<name>@<tag>` (see `npm-dist-tag(1)`) that points to (d)
|
||||
* f) a `<name>` that has a "latest" tag satisfying (e)
|
||||
* g) a `<git remote url>` that resolves to (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).
|
||||
|
||||
|
||||
* `npm install` (in package directory, no arguments):
|
||||
|
||||
Install the dependencies in the local node_modules folder.
|
||||
|
||||
In global mode (ie, with `-g` or `--global` appended to the command),
|
||||
it installs the current package context (ie, the current working
|
||||
directory) as a global package.
|
||||
|
||||
By default, `npm install` will install all modules listed as dependencies
|
||||
in `package.json(5)`.
|
||||
|
||||
With the `--production` flag (or when the `NODE_ENV` environment variable
|
||||
is set to `production`), npm will not install modules listed in
|
||||
`devDependencies`.
|
||||
|
||||
> NOTE: The `--production` flag has no particular meaning when adding a
|
||||
dependency to a project.
|
||||
|
||||
* `npm install <folder>`:
|
||||
|
||||
Install the package in the directory as a symlink in the current project.
|
||||
Its dependencies will be installed before it's linked. If `<folder>` sits
|
||||
inside the root of your project, its dependencies may be hoisted to the
|
||||
toplevel `node_modules` as they would for other types of dependencies.
|
||||
|
||||
* `npm install <tarball file>`:
|
||||
|
||||
Install a package that is sitting on the filesystem. Note: if you just want
|
||||
to link a dev directory into your npm root, you can do this more easily by
|
||||
using `npm link`.
|
||||
|
||||
Tarball requirements:
|
||||
* The filename *must* use `.tar`, `.tar.gz`, or `.tgz` as
|
||||
the extension.
|
||||
* The package contents should reside in a subfolder inside the tarball (usually it is called `package/`). npm strips one directory layer when installing the package (an equivalent of `tar x --strip-components=1` is run).
|
||||
* The package must contain a `package.json` file with `name` and `version` properties.
|
||||
|
||||
Example:
|
||||
|
||||
npm install ./package.tgz
|
||||
|
||||
* `npm install <tarball url>`:
|
||||
|
||||
Fetch the tarball url, and then install it. In order to distinguish between
|
||||
this and other options, the argument must start with "http://" or "https://"
|
||||
|
||||
Example:
|
||||
|
||||
npm install https://github.com/indexzero/forever/tarball/v0.5.6
|
||||
|
||||
* `npm install [<@scope>/]<name>`:
|
||||
|
||||
Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See
|
||||
`npm-config(7)`. The config's default value is `latest`.)
|
||||
|
||||
In most cases, this will install the version of the modules tagged as
|
||||
`latest` on the npm registry.
|
||||
|
||||
Example:
|
||||
|
||||
npm install sax
|
||||
|
||||
`npm install` saves any specified packages into `dependencies` by default.
|
||||
Additionally, you can control where and how they get saved with some
|
||||
additional flags:
|
||||
|
||||
* `-P, --save-prod`: Package will appear in your `dependencies`. This is the
|
||||
default unless `-D` or `-O` are present.
|
||||
|
||||
* `-D, --save-dev`: Package will appear in your `devDependencies`.
|
||||
|
||||
* `-O, --save-optional`: Package will appear in your `optionalDependencies`.
|
||||
|
||||
* `--no-save`: Prevents saving to `dependencies`.
|
||||
|
||||
When using any of the above options to save dependencies to your
|
||||
package.json, there are two additional, optional flags:
|
||||
|
||||
* `-E, --save-exact`: Saved dependencies will be configured with an
|
||||
exact version rather than using npm's default semver range
|
||||
operator.
|
||||
|
||||
* `-B, --save-bundle`: Saved dependencies will also be added to your `bundleDependencies` list.
|
||||
|
||||
Further, if you have an `npm-shrinkwrap.json` or `package-lock.json` then it
|
||||
will be updated as well.
|
||||
|
||||
`<scope>` is optional. The package will be downloaded from the registry
|
||||
associated with the specified scope. If no registry is associated with
|
||||
the given scope the default registry is assumed. See `npm-scope(7)`.
|
||||
|
||||
Note: if you do not include the @-symbol on your scope name, npm will
|
||||
interpret this as a GitHub repository instead, see below. Scopes names
|
||||
must also be followed by a slash.
|
||||
|
||||
Examples:
|
||||
|
||||
npm install sax
|
||||
npm install githubname/reponame
|
||||
npm install @myorg/privatepackage
|
||||
npm install node-tap --save-dev
|
||||
npm install dtrace-provider --save-optional
|
||||
npm install readable-stream --save-exact
|
||||
npm install ansi-regex --save-bundle
|
||||
|
||||
|
||||
**Note**: If there is a file or folder named `<name>` in the current
|
||||
working directory, then it will try to install that, and only try to
|
||||
fetch the package by name if it is not valid.
|
||||
|
||||
* `npm install [<@scope>/]<name>@<tag>`:
|
||||
|
||||
Install the version of the package that is referenced by the specified tag.
|
||||
If the tag does not exist in the registry data for that package, then this
|
||||
will fail.
|
||||
|
||||
Example:
|
||||
|
||||
npm install sax@latest
|
||||
npm install @myorg/mypackage@latest
|
||||
|
||||
* `npm install [<@scope>/]<name>@<version>`:
|
||||
|
||||
Install the specified version of the package. This will fail if the
|
||||
version has not been published to the registry.
|
||||
|
||||
Example:
|
||||
|
||||
npm install sax@0.1.1
|
||||
npm install @myorg/privatepackage@1.5.0
|
||||
|
||||
* `npm install [<@scope>/]<name>@<version range>`:
|
||||
|
||||
Install a version of the package matching the specified version range. This
|
||||
will follow the same rules for resolving dependencies described in `package.json(5)`.
|
||||
|
||||
Note that most version ranges must be put in quotes so that your shell will
|
||||
treat it as a single argument.
|
||||
|
||||
Example:
|
||||
|
||||
npm install sax@">=0.1.0 <0.2.0"
|
||||
npm install @myorg/privatepackage@">=0.1.0 <0.2.0"
|
||||
|
||||
* `npm install <git remote url>`:
|
||||
|
||||
Installs the package from the hosted git provider, cloning it with `git`.
|
||||
For a full git remote url, only that URL will be attempted.
|
||||
|
||||
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
|
||||
|
||||
`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
|
||||
`git+file`.
|
||||
|
||||
If `#<commit-ish>` is provided, it will be used to clone exactly that
|
||||
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
|
||||
be any valid semver range or exact version, and npm will look for any tags
|
||||
or refs matching that range in the remote repository, much as it would for a
|
||||
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
|
||||
specified, then the default branch of the repository is used.
|
||||
|
||||
If the repository makes use of submodules, those submodules will be cloned
|
||||
as well.
|
||||
|
||||
If the package being installed contains a `prepare` script, its
|
||||
`dependencies` and `devDependencies` will be installed, and the prepare
|
||||
script will be run, before the package is packaged and installed.
|
||||
|
||||
The following git environment variables are recognized by npm and will be
|
||||
added to the environment when running git:
|
||||
|
||||
* `GIT_ASKPASS`
|
||||
* `GIT_EXEC_PATH`
|
||||
* `GIT_PROXY_COMMAND`
|
||||
* `GIT_SSH`
|
||||
* `GIT_SSH_COMMAND`
|
||||
* `GIT_SSL_CAINFO`
|
||||
* `GIT_SSL_NO_VERIFY`
|
||||
|
||||
See the git man page for details.
|
||||
|
||||
Examples:
|
||||
|
||||
npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
|
||||
npm install git+ssh://git@github.com:npm/cli#semver:^5.0
|
||||
npm install git+https://isaacs@github.com/npm/cli.git
|
||||
npm install git://github.com/npm/cli.git#v1.0.27
|
||||
GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/cli.git
|
||||
|
||||
* `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
|
||||
* `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
|
||||
|
||||
Install the package at `https://github.com/githubname/githubrepo` by
|
||||
attempting to clone it using `git`.
|
||||
|
||||
If `#<commit-ish>` is provided, it will be used to clone exactly that
|
||||
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
|
||||
be any valid semver range or exact version, and npm will look for any tags
|
||||
or refs matching that range in the remote repository, much as it would for a
|
||||
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
|
||||
specified, then `master` is used.
|
||||
|
||||
As with regular git dependencies, `dependencies` and `devDependencies` will
|
||||
be installed if the package has a `prepare` script, before the package is
|
||||
done installing.
|
||||
|
||||
Examples:
|
||||
|
||||
npm install mygithubuser/myproject
|
||||
npm install github:mygithubuser/myproject
|
||||
|
||||
* `npm install gist:[<githubname>/]<gistID>[#<commit-ish>|#semver:<semver>]`:
|
||||
|
||||
Install the package at `https://gist.github.com/gistID` by attempting to
|
||||
clone it using `git`. The GitHub username associated with the gist is
|
||||
optional and will not be saved in `package.json`.
|
||||
|
||||
As with regular git dependencies, `dependencies` and `devDependencies` will
|
||||
be installed if the package has a `prepare` script, before the package is
|
||||
done installing.
|
||||
|
||||
Example:
|
||||
|
||||
npm install gist:101a11beef
|
||||
|
||||
* `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
|
||||
|
||||
Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo`
|
||||
by attempting to clone it using `git`.
|
||||
|
||||
If `#<commit-ish>` is provided, it will be used to clone exactly that
|
||||
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
|
||||
be any valid semver range or exact version, and npm will look for any tags
|
||||
or refs matching that range in the remote repository, much as it would for a
|
||||
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
|
||||
specified, then `master` is used.
|
||||
|
||||
As with regular git dependencies, `dependencies` and `devDependencies` will
|
||||
be installed if the package has a `prepare` script, before the package is
|
||||
done installing.
|
||||
|
||||
Example:
|
||||
|
||||
npm install bitbucket:mybitbucketuser/myproject
|
||||
|
||||
* `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
|
||||
|
||||
Install the package at `https://gitlab.com/gitlabname/gitlabrepo`
|
||||
by attempting to clone it using `git`.
|
||||
|
||||
If `#<commit-ish>` is provided, it will be used to clone exactly that
|
||||
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
|
||||
be any valid semver range or exact version, and npm will look for any tags
|
||||
or refs matching that range in the remote repository, much as it would for a
|
||||
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
|
||||
specified, then `master` is used.
|
||||
|
||||
As with regular git dependencies, `dependencies` and `devDependencies` will
|
||||
be installed if the package has a `prepare` script, before the package is
|
||||
done installing.
|
||||
|
||||
Example:
|
||||
|
||||
npm install gitlab:mygitlabuser/myproject
|
||||
npm install gitlab:myusr/myproj#semver:^5.0
|
||||
|
||||
You may combine multiple arguments, and even multiple types of arguments.
|
||||
For example:
|
||||
|
||||
npm install sax@">=0.1.0 <0.2.0" bench supervisor
|
||||
|
||||
The `--tag` argument will apply to all of the specified install targets. If a
|
||||
tag with the given name exists, the tagged version is preferred over newer
|
||||
versions.
|
||||
|
||||
The `--dry-run` argument will report in the usual way what the install would
|
||||
have done without actually installing anything.
|
||||
|
||||
The `--package-lock-only` argument will only update the `package-lock.json`,
|
||||
instead of checking `node_modules` and downloading dependencies.
|
||||
|
||||
The `-f` or `--force` argument will force npm to fetch remote resources even if a
|
||||
local copy exists on disk.
|
||||
|
||||
npm install sax --force
|
||||
|
||||
The `-g` or `--global` argument will cause npm to install the package globally
|
||||
rather than locally. See `npm-folders(5)`.
|
||||
|
||||
The `--global-style` argument will cause npm to install the package into
|
||||
your local `node_modules` folder with the same layout it uses with the
|
||||
global `node_modules` folder. Only your direct dependencies will show in
|
||||
`node_modules` and everything they depend on will be flattened in their
|
||||
`node_modules` folders. This obviously will eliminate some deduping.
|
||||
|
||||
The `--ignore-scripts` argument will cause npm to not execute any
|
||||
scripts defined in the package.json. See `npm-scripts(7)`.
|
||||
|
||||
The `--legacy-bundling` argument will cause npm to install the package such
|
||||
that versions of npm prior to 1.4, such as the one included with node 0.8,
|
||||
can install the package. This eliminates all automatic deduping.
|
||||
|
||||
The `--link` argument will cause npm to link global installs into the
|
||||
local space in some cases.
|
||||
|
||||
The `--no-bin-links` argument will prevent npm from creating symlinks for
|
||||
any binaries the package might contain.
|
||||
|
||||
The `--no-optional` argument will prevent optional dependencies from
|
||||
being installed.
|
||||
|
||||
The `--no-shrinkwrap` argument, which will ignore an available
|
||||
package lock or shrinkwrap file and use the package.json instead.
|
||||
|
||||
The `--no-package-lock` argument will prevent npm from creating a
|
||||
`package-lock.json` file. When running with package-lock's disabled npm
|
||||
will not automatically prune your node modules when installing.
|
||||
|
||||
The `--nodedir=/path/to/node/source` argument will allow npm to find the
|
||||
node source code so that npm can compile native modules.
|
||||
|
||||
The `--only={prod[uction]|dev[elopment]}` argument will cause either only
|
||||
`devDependencies` or only non-`devDependencies` to be installed regardless of the `NODE_ENV`.
|
||||
|
||||
The `--no-audit` argument can be used to disable sending of audit reports to
|
||||
the configured registries. See `npm-audit(1)` for details on what is sent.
|
||||
|
||||
See `npm-config(7)`. Many of the configuration params have some
|
||||
effect on installation, since that's most of what npm does.
|
||||
|
||||
## ALGORITHM
|
||||
|
||||
To install a package, npm uses the following algorithm:
|
||||
|
||||
load the existing node_modules tree from disk
|
||||
clone the tree
|
||||
fetch the package.json and assorted metadata and add it to the clone
|
||||
walk the clone and add any missing dependencies
|
||||
dependencies will be added as close to the top as is possible
|
||||
without breaking any other modules
|
||||
compare the original tree with the cloned tree and make a list of
|
||||
actions to take to convert one to the other
|
||||
execute all of the actions, deepest first
|
||||
kinds of actions are install, update, remove and move
|
||||
|
||||
For this `package{dep}` structure: `A{B,C}, B{C}, C{D}`,
|
||||
this algorithm produces:
|
||||
|
||||
A
|
||||
+-- B
|
||||
+-- C
|
||||
+-- D
|
||||
|
||||
That is, the dependency from B to C is satisfied by the fact that A
|
||||
already caused C to be installed at a higher level. D is still installed
|
||||
at the top level because nothing conflicts with it.
|
||||
|
||||
For `A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces:
|
||||
|
||||
A
|
||||
+-- B
|
||||
+-- C
|
||||
`-- D@2
|
||||
+-- D@1
|
||||
|
||||
Because B's D@1 will be installed in the top level, C now has to install D@2
|
||||
privately for itself. This algorithm is deterministic, but different trees may
|
||||
be produced if two dependencies are requested for installation in a different
|
||||
order.
|
||||
|
||||
See npm-folders(5) for a more detailed description of the specific
|
||||
folder structures that npm creates.
|
||||
|
||||
### Limitations of npm's Install Algorithm
|
||||
|
||||
npm will refuse to install any package with an identical name to the
|
||||
current package. This can be overridden with the `--force` flag, but in
|
||||
most cases can simply be addressed by changing the local package name.
|
||||
|
||||
There are some very rare and pathological edge-cases where a cycle can
|
||||
cause npm to try to install a never-ending tree of packages. Here is
|
||||
the simplest case:
|
||||
|
||||
A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ...
|
||||
|
||||
where `A` is some version of a package, and `A'` is a different version
|
||||
of the same package. Because `B` depends on a different version of `A`
|
||||
than the one that is already in the tree, it must install a separate
|
||||
copy. The same is true of `A'`, which must install `B'`. Because `B'`
|
||||
depends on the original version of `A`, which has been overridden, the
|
||||
cycle falls into infinite regress.
|
||||
|
||||
To avoid this situation, npm flat-out refuses to install any
|
||||
`name@version` that is already present anywhere in the tree of package
|
||||
folder ancestors. A more correct, but more complex, solution would be
|
||||
to symlink the existing version into the new location. If this ever
|
||||
affects a real use-case, it will be investigated.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-folders(5)
|
||||
* npm-update(1)
|
||||
* npm-audit(1)
|
||||
* npm-link(1)
|
||||
* npm-rebuild(1)
|
||||
* npm-scripts(7)
|
||||
* npm-build(1)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* npm-registry(7)
|
||||
* npm-dist-tag(1)
|
||||
* npm-uninstall(1)
|
||||
* npm-shrinkwrap(1)
|
||||
* package.json(5)
|
||||
77
website/node_modules/npm/doc/cli/npm-link.md
generated
vendored
Normal file
77
website/node_modules/npm/doc/cli/npm-link.md
generated
vendored
Normal file
@@ -0,0 +1,77 @@
|
||||
npm-link(1) -- Symlink a package folder
|
||||
=======================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm link (in package dir)
|
||||
npm link [<@scope>/]<pkg>[@<version>]
|
||||
|
||||
alias: npm ln
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Package linking is a two-step process.
|
||||
|
||||
First, `npm link` in a package folder will create a symlink in the global folder
|
||||
`{prefix}/lib/node_modules/<package>` that links to the package where the `npm
|
||||
link` command was executed. (see `npm-config(7)` for the value of `prefix`). It
|
||||
will also link any bins in the package to `{prefix}/bin/{name}`.
|
||||
|
||||
Next, in some other location, `npm link package-name` will create a
|
||||
symbolic link from globally-installed `package-name` to `node_modules/`
|
||||
of the current folder.
|
||||
|
||||
Note that `package-name` is taken from `package.json`,
|
||||
not from directory name.
|
||||
|
||||
The package name can be optionally prefixed with a scope. See `npm-scope(7)`.
|
||||
The scope must be preceded by an @-symbol and followed by a slash.
|
||||
|
||||
When creating tarballs for `npm publish`, the linked packages are
|
||||
"snapshotted" to their current state by resolving the symbolic links.
|
||||
|
||||
This is handy for installing your own stuff, so that you can work on it and
|
||||
test it iteratively without having to continually rebuild.
|
||||
|
||||
For example:
|
||||
|
||||
cd ~/projects/node-redis # go into the package directory
|
||||
npm link # creates global link
|
||||
cd ~/projects/node-bloggy # go into some other package directory.
|
||||
npm link redis # link-install the package
|
||||
|
||||
Now, any changes to ~/projects/node-redis will be reflected in
|
||||
~/projects/node-bloggy/node_modules/node-redis/. Note that the link should
|
||||
be to the package name, not the directory name for that package.
|
||||
|
||||
You may also shortcut the two steps in one. For example, to do the
|
||||
above use-case in a shorter way:
|
||||
|
||||
cd ~/projects/node-bloggy # go into the dir of your main project
|
||||
npm link ../node-redis # link the dir of your dependency
|
||||
|
||||
The second line is the equivalent of doing:
|
||||
|
||||
(cd ../node-redis; npm link)
|
||||
npm link redis
|
||||
|
||||
That is, it first creates a global link, and then links the global
|
||||
installation target into your project's `node_modules` folder.
|
||||
|
||||
Note that in this case, you are referring to the directory name, `node-redis`,
|
||||
rather than the package name `redis`.
|
||||
|
||||
If your linked package is scoped (see `npm-scope(7)`) your link command must
|
||||
include that scope, e.g.
|
||||
|
||||
npm link @myorg/privatepackage
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-developers(7)
|
||||
* package.json(5)
|
||||
* npm-install(1)
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
45
website/node_modules/npm/doc/cli/npm-logout.md
generated
vendored
Normal file
45
website/node_modules/npm/doc/cli/npm-logout.md
generated
vendored
Normal file
@@ -0,0 +1,45 @@
|
||||
npm-logout(1) -- Log out of the registry
|
||||
========================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm logout [--registry=<url>] [--scope=<@scope>]
|
||||
|
||||
## 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: The scope of your current project, if any, otherwise 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)
|
||||
111
website/node_modules/npm/doc/cli/npm-ls.md
generated
vendored
Normal file
111
website/node_modules/npm/doc/cli/npm-ls.md
generated
vendored
Normal file
@@ -0,0 +1,111 @@
|
||||
npm-ls(1) -- List installed packages
|
||||
======================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm ls [[<@scope>/]<pkg> ...]
|
||||
|
||||
aliases: list, la, ll
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command will print to stdout all the versions of packages that are
|
||||
installed, as well as their dependencies, in a tree-structure.
|
||||
|
||||
Positional arguments are `name@version-range` identifiers, which will
|
||||
limit the results to only the paths to the packages named. Note that
|
||||
nested packages will *also* show the paths to the specified packages.
|
||||
For example, running `npm ls promzard` in npm's source tree will show:
|
||||
|
||||
npm@@VERSION@ /path/to/npm
|
||||
└─┬ init-package-json@0.0.4
|
||||
└── promzard@0.1.5
|
||||
|
||||
It will print out extraneous, missing, and invalid packages.
|
||||
|
||||
If a project specifies git urls for dependencies these are shown
|
||||
in parentheses after the name@version to make it easier for users to
|
||||
recognize potential forks of a project.
|
||||
|
||||
The tree shown is the logical dependency tree, based on package
|
||||
dependencies, not the physical layout of your node_modules folder.
|
||||
|
||||
When run as `ll` or `la`, it shows extended information by default.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### json
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Show information in JSON format.
|
||||
|
||||
### long
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Show extended information.
|
||||
|
||||
### parseable
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Show parseable output instead of tree view.
|
||||
|
||||
### global
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
List packages in the global install prefix instead of in the current
|
||||
project.
|
||||
|
||||
### depth
|
||||
|
||||
* Type: Int
|
||||
|
||||
Max display depth of the dependency tree.
|
||||
|
||||
### prod / production
|
||||
|
||||
* Type: Boolean
|
||||
* Default: false
|
||||
|
||||
Display only the dependency tree for packages in `dependencies`.
|
||||
|
||||
### dev / development
|
||||
|
||||
* Type: Boolean
|
||||
* Default: false
|
||||
|
||||
Display only the dependency tree for packages in `devDependencies`.
|
||||
|
||||
### only
|
||||
|
||||
* Type: String
|
||||
|
||||
When "dev" or "development", is an alias to `dev`.
|
||||
|
||||
When "prod" or "production", is an alias to `production`.
|
||||
|
||||
### link
|
||||
|
||||
* Type: Boolean
|
||||
* Default: false
|
||||
|
||||
Display only dependencies which are linked
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* npm-folders(5)
|
||||
* npm-install(1)
|
||||
* npm-link(1)
|
||||
* npm-prune(1)
|
||||
* npm-outdated(1)
|
||||
* npm-update(1)
|
||||
115
website/node_modules/npm/doc/cli/npm-outdated.md
generated
vendored
Normal file
115
website/node_modules/npm/doc/cli/npm-outdated.md
generated
vendored
Normal file
@@ -0,0 +1,115 @@
|
||||
npm-outdated(1) -- Check for outdated packages
|
||||
==============================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm outdated [[<@scope>/]<pkg> ...]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command will check the registry to see if any (or, specific) installed
|
||||
packages are currently outdated.
|
||||
|
||||
In the output:
|
||||
|
||||
* `wanted` is the maximum version of the package that satisfies the semver
|
||||
range specified in `package.json`. If there's no available semver range (i.e.
|
||||
you're running `npm outdated --global`, or the package isn't included in
|
||||
`package.json`), then `wanted` shows the currently-installed version.
|
||||
* `latest` is the version of the package tagged as latest in the registry.
|
||||
Running `npm publish` with no special configuration will publish the package
|
||||
with a dist-tag of `latest`. This may or may not be the maximum version of
|
||||
the package, or the most-recently published version of the package, depending
|
||||
on how the package's developer manages the latest dist-tag(1).
|
||||
* `location` is where in the dependency tree the package is located. Note that
|
||||
`npm outdated` defaults to a depth of 0, so unless you override that, you'll
|
||||
always be seeing only top-level dependencies that are outdated.
|
||||
* `package type` (when using `--long` / `-l`) tells you whether this package is
|
||||
a `dependency` or a `devDependency`. Packages not included in `package.json`
|
||||
are always marked `dependencies`.
|
||||
* `homepage` (when using `--long` / `-l`) is the `homepage` value contained in the package's `package.json`
|
||||
* Red means there's a newer version matching your semver requirements, so you should update now.
|
||||
* Yellow indicates that there's a newer version above your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
|
||||
|
||||
### An example
|
||||
|
||||
```
|
||||
$ npm outdated
|
||||
Package Current Wanted Latest Location
|
||||
glob 5.0.15 5.0.15 6.0.1 test-outdated-output
|
||||
nothingness 0.0.3 git git test-outdated-output
|
||||
npm 3.5.1 3.5.2 3.5.1 test-outdated-output
|
||||
local-dev 0.0.3 linked linked test-outdated-output
|
||||
once 1.3.2 1.3.3 1.3.3 test-outdated-output
|
||||
```
|
||||
|
||||
With these `dependencies`:
|
||||
```json
|
||||
{
|
||||
"glob": "^5.0.15",
|
||||
"nothingness": "github:othiym23/nothingness#master",
|
||||
"npm": "^3.5.1",
|
||||
"once": "^1.3.1"
|
||||
}
|
||||
```
|
||||
|
||||
A few things to note:
|
||||
|
||||
* `glob` requires `^5`, which prevents npm from installing `glob@6`, which is
|
||||
outside the semver range.
|
||||
* Git dependencies will always be reinstalled, because of how they're specified.
|
||||
The installed committish might satisfy the dependency specifier (if it's
|
||||
something immutable, like a commit SHA), or it might not, so `npm outdated` and
|
||||
`npm update` have to fetch Git repos to check. This is why currently doing a
|
||||
reinstall of a Git dependency always forces a new clone and install.
|
||||
* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm
|
||||
uses dist-tags to manage its `latest` and `next` release channels. `npm update`
|
||||
will install the _newest_ version, but `npm install npm` (with no semver range)
|
||||
will install whatever's tagged as `latest`.
|
||||
* `once` is just plain out of date. Reinstalling `node_modules` from scratch or
|
||||
running `npm update` will bring it up to spec.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### json
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Show information in JSON format.
|
||||
|
||||
### long
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Show extended information.
|
||||
|
||||
### parseable
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Show parseable output instead of tree view.
|
||||
|
||||
### global
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Check packages in the global install prefix instead of in the current
|
||||
project.
|
||||
|
||||
### depth
|
||||
|
||||
* Default: 0
|
||||
* Type: Int
|
||||
|
||||
Max depth for checking dependency tree.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-update(1)
|
||||
* npm-dist-tag(1)
|
||||
* npm-registry(7)
|
||||
* npm-folders(5)
|
||||
39
website/node_modules/npm/doc/cli/npm-owner.md
generated
vendored
Normal file
39
website/node_modules/npm/doc/cli/npm-owner.md
generated
vendored
Normal file
@@ -0,0 +1,39 @@
|
||||
npm-owner(1) -- Manage package owners
|
||||
=====================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm owner add <user> [<@scope>/]<pkg>
|
||||
npm owner rm <user> [<@scope>/]<pkg>
|
||||
npm owner ls [<@scope>/]<pkg>
|
||||
|
||||
aliases: author
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Manage ownership of published packages.
|
||||
|
||||
* ls:
|
||||
List all the users who have access to modify a package and push new versions.
|
||||
Handy when you need to know who to bug for help.
|
||||
* add:
|
||||
Add a new user as a maintainer of a package. This user is enabled to modify
|
||||
metadata, publish new versions, and add other owners.
|
||||
* rm:
|
||||
Remove a user from the package owner list. This immediately revokes their
|
||||
privileges.
|
||||
|
||||
Note that there is only one level of access. Either you can modify a package,
|
||||
or you can't. Future versions may contain more fine-grained access levels, but
|
||||
that is not implemented at this time.
|
||||
|
||||
If you have two-factor authentication enabled with `auth-and-writes` then
|
||||
you'll need to include an otp on the command line when changing ownership
|
||||
with `--otp`.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-publish(1)
|
||||
* npm-registry(7)
|
||||
* npm-adduser(1)
|
||||
* npm-disputes(7)
|
||||
30
website/node_modules/npm/doc/cli/npm-pack.md
generated
vendored
Normal file
30
website/node_modules/npm/doc/cli/npm-pack.md
generated
vendored
Normal file
@@ -0,0 +1,30 @@
|
||||
npm-pack(1) -- Create a tarball from a package
|
||||
==============================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm pack [[<@scope>/]<pkg>...] [--dry-run]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
For anything that's installable (that is, a package folder, tarball,
|
||||
tarball url, name@tag, name@version, name, or scoped name), this
|
||||
command will fetch it to the cache, and then copy the tarball to the
|
||||
current working directory as `<name>-<version>.tgz`, and then write
|
||||
the filenames out to stdout.
|
||||
|
||||
If the same package is specified multiple times, then the file will be
|
||||
overwritten the second time.
|
||||
|
||||
If no arguments are supplied, then npm packs the current package folder.
|
||||
|
||||
The `--dry-run` argument will do everything that pack usually does without
|
||||
actually packing anything. Reports on what would have gone into the tarball.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-cache(1)
|
||||
* npm-publish(1)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
24
website/node_modules/npm/doc/cli/npm-ping.md
generated
vendored
Normal file
24
website/node_modules/npm/doc/cli/npm-ping.md
generated
vendored
Normal file
@@ -0,0 +1,24 @@
|
||||
npm-ping(1) -- Ping npm registry
|
||||
================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm ping [--registry <registry>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Ping the configured or given npm registry and verify authentication.
|
||||
If it works it will output something like:
|
||||
```
|
||||
Ping success: {*Details about registry*}
|
||||
```
|
||||
otherwise you will get:
|
||||
```
|
||||
Ping error: {*Detail about error}
|
||||
```
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
23
website/node_modules/npm/doc/cli/npm-prefix.md
generated
vendored
Normal file
23
website/node_modules/npm/doc/cli/npm-prefix.md
generated
vendored
Normal file
@@ -0,0 +1,23 @@
|
||||
npm-prefix(1) -- Display prefix
|
||||
===============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm prefix [-g]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Print the local prefix to standard out. This is the closest parent directory
|
||||
to contain a package.json file unless `-g` is also specified.
|
||||
|
||||
If `-g` is specified, this will be the value of the global prefix. See
|
||||
`npm-config(7)` for more detail.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-root(1)
|
||||
* npm-bin(1)
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
74
website/node_modules/npm/doc/cli/npm-profile.md
generated
vendored
Normal file
74
website/node_modules/npm/doc/cli/npm-profile.md
generated
vendored
Normal file
@@ -0,0 +1,74 @@
|
||||
npm-profile(1) -- Change settings on your registry profile
|
||||
==========================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm profile get [--json|--parseable] [<property>]
|
||||
npm profile set [--json|--parseable] <property> <value>
|
||||
npm profile set password
|
||||
npm profile enable-2fa [auth-and-writes|auth-only]
|
||||
npm profile disable-2fa
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Change your profile information on the registry. This not be available if
|
||||
you're using a non-npmjs registry.
|
||||
|
||||
* `npm profile get [<property>]`:
|
||||
Display all of the properties of your profile, or one or more specific
|
||||
properties. It looks like:
|
||||
|
||||
```
|
||||
+-----------------+---------------------------+
|
||||
| name | example |
|
||||
+-----------------+---------------------------+
|
||||
| email | me@example.com (verified) |
|
||||
+-----------------+---------------------------+
|
||||
| two factor auth | auth-and-writes |
|
||||
+-----------------+---------------------------+
|
||||
| fullname | Example User |
|
||||
+-----------------+---------------------------+
|
||||
| homepage | |
|
||||
+-----------------+---------------------------+
|
||||
| freenode | |
|
||||
+-----------------+---------------------------+
|
||||
| twitter | |
|
||||
+-----------------+---------------------------+
|
||||
| github | |
|
||||
+-----------------+---------------------------+
|
||||
| created | 2015-02-26T01:38:35.892Z |
|
||||
+-----------------+---------------------------+
|
||||
| updated | 2017-10-02T21:29:45.922Z |
|
||||
+-----------------+---------------------------+
|
||||
```
|
||||
|
||||
* `npm profile set <property> <value>`:
|
||||
Set the value of a profile property. You can set the following properties this way:
|
||||
email, fullname, homepage, freenode, twitter, github
|
||||
|
||||
* `npm profile set password`:
|
||||
Change your password. This is interactive, you'll be prompted for your
|
||||
current password and a new password. You'll also be prompted for an OTP
|
||||
if you have two-factor authentication enabled.
|
||||
|
||||
* `npm profile enable-2fa [auth-and-writes|auth-only]`:
|
||||
Enables two-factor authentication. Defaults to `auth-and-writes` mode. Modes are:
|
||||
* `auth-only`: Require an OTP when logging in or making changes to your
|
||||
account's authentication. The OTP will be required on both the website
|
||||
and the command line.
|
||||
* `auth-and-writes`: Requires an OTP at all the times `auth-only` does, and also requires one when
|
||||
publishing a module, setting the `latest` dist-tag, or changing access
|
||||
via `npm access` and `npm owner`.
|
||||
|
||||
* `npm profile disable-2fa`:
|
||||
Disables two-factor authentication.
|
||||
|
||||
## DETAILS
|
||||
|
||||
All of the `npm profile` subcommands accept `--json` and `--parseable` and
|
||||
will tailor their output based on those. Some of these commands may not be
|
||||
available on non npmjs.com registries.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-config(7)
|
||||
38
website/node_modules/npm/doc/cli/npm-prune.md
generated
vendored
Normal file
38
website/node_modules/npm/doc/cli/npm-prune.md
generated
vendored
Normal file
@@ -0,0 +1,38 @@
|
||||
npm-prune(1) -- Remove extraneous packages
|
||||
==========================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm prune [[<@scope>/]<pkg>...] [--production] [--dry-run] [--json]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command removes "extraneous" packages. If a package name is
|
||||
provided, then only packages matching one of the supplied names are
|
||||
removed.
|
||||
|
||||
Extraneous packages are packages that are not listed on the parent
|
||||
package's dependencies list.
|
||||
|
||||
If the `--production` flag is specified or the `NODE_ENV` environment
|
||||
variable is set to `production`, this command will remove the packages
|
||||
specified in your `devDependencies`. Setting `--no-production` will
|
||||
negate `NODE_ENV` being set to `production`.
|
||||
|
||||
If the `--dry-run` flag is used then no changes will actually be made.
|
||||
|
||||
If the `--json` flag is used then the changes `npm prune` made (or would
|
||||
have made with `--dry-run`) are printed as a JSON object.
|
||||
|
||||
In normal operation with package-locks enabled, extraneous modules are
|
||||
pruned automatically when modules are installed and you'll only need
|
||||
this command with the `--production` flag.
|
||||
|
||||
If you've disabled package-locks then extraneous modules will not be removed
|
||||
and it's up to you to run `npm prune` from time-to-time to remove them.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-uninstall(1)
|
||||
* npm-folders(5)
|
||||
* npm-ls(1)
|
||||
76
website/node_modules/npm/doc/cli/npm-publish.md
generated
vendored
Normal file
76
website/node_modules/npm/doc/cli/npm-publish.md
generated
vendored
Normal file
@@ -0,0 +1,76 @@
|
||||
npm-publish(1) -- Publish a package
|
||||
===================================
|
||||
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm publish [<tarball>|<folder>] [--tag <tag>] [--access <public|restricted>] [--otp otpcode] [--dry-run]
|
||||
|
||||
Publishes '.' if no argument supplied
|
||||
Sets tag 'latest' if no --tag specified
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Publishes a package to the registry so that it can be installed by name. All
|
||||
files in the package directory are included if no local `.gitignore` or
|
||||
`.npmignore` file exists. If both files exist and a file is ignored by
|
||||
`.gitignore` but not by `.npmignore` then it will be included. See
|
||||
`npm-developers(7)` for full details on what's included in the published
|
||||
package, as well as details on how the package is built.
|
||||
|
||||
By default npm will publish to the public registry. This can be overridden by
|
||||
specifying a different default registry or using a `npm-scope(7)` in the name
|
||||
(see `package.json(5)`).
|
||||
|
||||
* `<folder>`:
|
||||
A folder containing a package.json file
|
||||
|
||||
* `<tarball>`:
|
||||
A url or file path to a gzipped tar archive containing a single folder
|
||||
with a package.json file inside.
|
||||
|
||||
* `[--tag <tag>]`
|
||||
Registers the published package with the given tag, such that `npm install
|
||||
<name>@<tag>` will install this version. By default, `npm publish` updates
|
||||
and `npm install` installs the `latest` tag. See `npm-dist-tag(1)` for
|
||||
details about tags.
|
||||
|
||||
* `[--access <public|restricted>]`
|
||||
Tells the registry whether this package should be published as public or
|
||||
restricted. Only applies to scoped packages, which default to `restricted`.
|
||||
If you don't have a paid account, you must publish with `--access public`
|
||||
to publish scoped packages.
|
||||
|
||||
* `[--otp <otpcode>]`
|
||||
If you have two-factor authentication enabled in `auth-and-writes` mode
|
||||
then you can provide a code from your authenticator with this. If you
|
||||
don't include this and you're running from a TTY then you'll be prompted.
|
||||
|
||||
* `[--dry-run]`
|
||||
As of `npm@6`, does everything publish would do except actually publishing
|
||||
to the registry. Reports the details of what would have been published.
|
||||
|
||||
Fails if the package name and version combination already exists in
|
||||
the specified registry.
|
||||
|
||||
Once a package is published with a given name and version, that
|
||||
specific name and version combination can never be used again, even if
|
||||
it is removed with npm-unpublish(1).
|
||||
|
||||
As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the
|
||||
tarball will be submitted to the registry during publication. Subsequent
|
||||
installs will use the strongest supported algorithm to verify downloads.
|
||||
|
||||
Similar to `--dry-run` see `npm-pack(1)`, which figures out the files to be
|
||||
included and packs them into a tarball to be uploaded to the registry.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-registry(7)
|
||||
* npm-scope(7)
|
||||
* npm-adduser(1)
|
||||
* npm-owner(1)
|
||||
* npm-deprecate(1)
|
||||
* npm-dist-tag(1)
|
||||
* npm-pack(1)
|
||||
* npm-profile(1)
|
||||
19
website/node_modules/npm/doc/cli/npm-rebuild.md
generated
vendored
Normal file
19
website/node_modules/npm/doc/cli/npm-rebuild.md
generated
vendored
Normal file
@@ -0,0 +1,19 @@
|
||||
npm-rebuild(1) -- Rebuild a package
|
||||
===================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm rebuild [[<@scope>/<name>]...]
|
||||
|
||||
alias: npm rb
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command runs the `npm build` command on the matched folders. This is useful
|
||||
when you install a new version of node, and must recompile all your C++ addons with
|
||||
the new binary.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-build(1)
|
||||
* npm-install(1)
|
||||
27
website/node_modules/npm/doc/cli/npm-repo.md
generated
vendored
Normal file
27
website/node_modules/npm/doc/cli/npm-repo.md
generated
vendored
Normal file
@@ -0,0 +1,27 @@
|
||||
npm-repo(1) -- Open package repository page in the browser
|
||||
========================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm repo [<pkg>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command tries to guess at the likely location of a package's
|
||||
repository URL, and then tries to open it using the `--browser`
|
||||
config param. If no package name is provided, it will search for
|
||||
a `package.json` in the current folder and use the `name` property.
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### browser
|
||||
|
||||
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
|
||||
* Type: String
|
||||
|
||||
The browser that is called by the `npm repo` command to open websites.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-docs(1)
|
||||
* npm-config(1)
|
||||
40
website/node_modules/npm/doc/cli/npm-restart.md
generated
vendored
Normal file
40
website/node_modules/npm/doc/cli/npm-restart.md
generated
vendored
Normal file
@@ -0,0 +1,40 @@
|
||||
npm-restart(1) -- Restart a package
|
||||
===================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm restart [-- <args>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This restarts a package.
|
||||
|
||||
This runs a package's "stop", "restart", and "start" scripts, and associated
|
||||
pre- and post- scripts, in the order given below:
|
||||
|
||||
1. prerestart
|
||||
2. prestop
|
||||
3. stop
|
||||
4. poststop
|
||||
5. restart
|
||||
6. prestart
|
||||
7. start
|
||||
8. poststart
|
||||
9. postrestart
|
||||
|
||||
## NOTE
|
||||
|
||||
Note that the "restart" script is run **in addition to** the "stop"
|
||||
and "start" scripts, not instead of them.
|
||||
|
||||
This is the behavior as of `npm` major version 2. A change in this
|
||||
behavior will be accompanied by an increase in major version number
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-run-script(1)
|
||||
* npm-scripts(7)
|
||||
* npm-test(1)
|
||||
* npm-start(1)
|
||||
* npm-stop(1)
|
||||
* npm-restart(3)
|
||||
19
website/node_modules/npm/doc/cli/npm-root.md
generated
vendored
Normal file
19
website/node_modules/npm/doc/cli/npm-root.md
generated
vendored
Normal file
@@ -0,0 +1,19 @@
|
||||
npm-root(1) -- Display npm root
|
||||
===============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm root [-g]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Print the effective `node_modules` folder to standard out.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-prefix(1)
|
||||
* npm-bin(1)
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
82
website/node_modules/npm/doc/cli/npm-run-script.md
generated
vendored
Normal file
82
website/node_modules/npm/doc/cli/npm-run-script.md
generated
vendored
Normal file
@@ -0,0 +1,82 @@
|
||||
npm-run-script(1) -- Run arbitrary package scripts
|
||||
==================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm run-script <command> [--silent] [-- <args>...]
|
||||
|
||||
alias: npm run
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This runs an arbitrary command from a package's `"scripts"` object. If no
|
||||
`"command"` is provided, it will list the available scripts. `run[-script]` is
|
||||
used by the test, start, restart, and stop commands, but can be called
|
||||
directly, as well. When the scripts in the package are printed out, they're
|
||||
separated into lifecycle (test, start, restart) and directly-run scripts.
|
||||
|
||||
As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
|
||||
use custom arguments when executing scripts. The special option `--` is used by
|
||||
[getopt](https://goo.gl/KxMmtG) to delimit the end of the options. npm will pass
|
||||
all the arguments after the `--` directly to your script:
|
||||
|
||||
npm run test -- --grep="pattern"
|
||||
|
||||
The arguments will only be passed to the script specified after ```npm run```
|
||||
and not to any pre or post script.
|
||||
|
||||
The `env` script is a special built-in command that can be used to list
|
||||
environment variables that will be available to the script at runtime. If an
|
||||
"env" command is defined in your package, it will take precedence over the
|
||||
built-in.
|
||||
|
||||
In addition to the shell's pre-existing `PATH`, `npm run` adds
|
||||
`node_modules/.bin` to the `PATH` provided to scripts. Any binaries provided by
|
||||
locally-installed dependencies can be used without the `node_modules/.bin`
|
||||
prefix. For example, if there is a `devDependency` on `tap` in your package,
|
||||
you should write:
|
||||
|
||||
"scripts": {"test": "tap test/\*.js"}
|
||||
|
||||
instead of
|
||||
|
||||
"scripts": {"test": "node_modules/.bin/tap test/\*.js"}
|
||||
|
||||
to run your tests.
|
||||
|
||||
The actual shell your script is run within is platform dependent. By default,
|
||||
on Unix-like systems it is the `/bin/sh` command, on Windows it is the `cmd.exe`.
|
||||
The actual shell referred to by `/bin/sh` also depends on the system.
|
||||
As of [`npm@5.1.0`](https://github.com/npm/npm/releases/tag/v5.1.0) you can
|
||||
customize the shell with the `script-shell` configuration.
|
||||
|
||||
Scripts are run from the root of the module, regardless of what your current
|
||||
working directory is when you call `npm run`. If you want your script to
|
||||
use different behavior based on what subdirectory you're in, you can use the
|
||||
`INIT_CWD` environment variable, which holds the full path you were in when
|
||||
you ran `npm run`.
|
||||
|
||||
`npm run` sets the `NODE` environment variable to the `node` executable with
|
||||
which `npm` is executed. Also, if the `--scripts-prepend-node-path` is passed,
|
||||
the directory within which `node` resides is added to the
|
||||
`PATH`. If `--scripts-prepend-node-path=auto` is passed (which has been the
|
||||
default in `npm` v3), this is only performed when that `node` executable is
|
||||
not found in the `PATH`.
|
||||
|
||||
If you try to run a script without having a `node_modules` directory and it fails,
|
||||
you will be given a warning to run `npm install`, just in case you've forgotten.
|
||||
|
||||
You can use the `--silent` flag to prevent showing `npm ERR!` output on error.
|
||||
|
||||
You can use the `--if-present` flag to avoid exiting with a non-zero exit code
|
||||
when the script is undefined. This lets you run potentially undefined scripts
|
||||
without breaking the execution chain.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-scripts(7)
|
||||
* npm-test(1)
|
||||
* npm-start(1)
|
||||
* npm-restart(1)
|
||||
* npm-stop(1)
|
||||
* npm-config(7)
|
||||
106
website/node_modules/npm/doc/cli/npm-search.md
generated
vendored
Normal file
106
website/node_modules/npm/doc/cli/npm-search.md
generated
vendored
Normal file
@@ -0,0 +1,106 @@
|
||||
npm-search(1) -- Search for packages
|
||||
====================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm search [-l|--long] [--json] [--parseable] [--no-description] [search terms ...]
|
||||
|
||||
aliases: s, se, find
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Search the registry for packages matching the search terms. `npm search`
|
||||
performs a linear, incremental, lexically-ordered search through package
|
||||
metadata for all files in the registry. If color is enabled, it will further
|
||||
highlight the matches in the results.
|
||||
|
||||
Additionally, using the `--searchopts` and `--searchexclude` options paired with
|
||||
more search terms will respectively include and exclude further patterns. The
|
||||
main difference between `--searchopts` and the standard search terms is that the
|
||||
former does not highlight results in the output and can be used for more
|
||||
fine-grained filtering. Additionally, both of these can be added to `.npmrc` for
|
||||
default search filtering behavior.
|
||||
|
||||
Search also allows targeting of maintainers in search results, by prefixing
|
||||
their npm username with `=`.
|
||||
|
||||
If a term starts with `/`, then it's interpreted as a regular expression and
|
||||
supports standard JavaScript RegExp syntax. A trailing `/` will be ignored in
|
||||
this case. (Note that many regular expression characters must be escaped or
|
||||
quoted in most shells.)
|
||||
|
||||
### A Note on caching
|
||||
|
||||
## CONFIGURATION
|
||||
|
||||
### description
|
||||
|
||||
* Default: true
|
||||
* Type: Boolean
|
||||
|
||||
Used as `--no-description`, disables search matching in package descriptions and
|
||||
suppresses display of that field in results.
|
||||
|
||||
### json
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Output search results as a JSON array.
|
||||
|
||||
### parseable
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Output search results as lines with tab-separated columns.
|
||||
|
||||
### long
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Display full package descriptions and other long text across multiple
|
||||
lines. When disabled (default) search results are truncated to fit
|
||||
neatly on a single line. Modules with extremely long names will
|
||||
fall on multiple lines.
|
||||
|
||||
### searchopts
|
||||
|
||||
* Default: ""
|
||||
* Type: String
|
||||
|
||||
Space-separated options that are always passed to search.
|
||||
|
||||
### searchexclude
|
||||
|
||||
* Default: ""
|
||||
* Type: String
|
||||
|
||||
Space-separated options that limit the results from search.
|
||||
|
||||
### searchstaleness
|
||||
|
||||
* Default: 900 (15 minutes)
|
||||
* Type: Number
|
||||
|
||||
The age of the cache, in seconds, before another registry request is made.
|
||||
|
||||
### registry
|
||||
|
||||
* Default: https://registry.npmjs.org/
|
||||
* Type: url
|
||||
|
||||
Search the specified registry for modules. If you have configured npm to point
|
||||
to a different default registry, such as your internal private module
|
||||
repository, `npm search` will default to that registry when searching. Pass a
|
||||
different registry url such as the default above in order to override this
|
||||
setting.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-registry(7)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* npm-view(1)
|
||||
25
website/node_modules/npm/doc/cli/npm-shrinkwrap.md
generated
vendored
Normal file
25
website/node_modules/npm/doc/cli/npm-shrinkwrap.md
generated
vendored
Normal file
@@ -0,0 +1,25 @@
|
||||
npm-shrinkwrap(1) -- Lock down dependency versions for publication
|
||||
=====================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm shrinkwrap
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command repurposes `package-lock.json` into a publishable
|
||||
`npm-shrinkwrap.json` or simply creates a new one. The file created and updated
|
||||
by this command will then take precedence over any other existing or future
|
||||
`package-lock.json` files. For a detailed explanation of the design and purpose
|
||||
of package locks in npm, see npm-package-locks(5).
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-install(1)
|
||||
* npm-run-script(1)
|
||||
* npm-scripts(7)
|
||||
* package.json(5)
|
||||
* npm-package-locks(5)
|
||||
* package-lock.json(5)
|
||||
* npm-shrinkwrap.json(5)
|
||||
* npm-ls(1)
|
||||
22
website/node_modules/npm/doc/cli/npm-star.md
generated
vendored
Normal file
22
website/node_modules/npm/doc/cli/npm-star.md
generated
vendored
Normal file
@@ -0,0 +1,22 @@
|
||||
npm-star(1) -- Mark your favorite packages
|
||||
==========================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm star [<pkg>...]
|
||||
npm unstar [<pkg>...]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
"Starring" a package means that you have some interest in it. It's
|
||||
a vaguely positive way to show that you care.
|
||||
|
||||
"Unstarring" is the same thing, but in reverse.
|
||||
|
||||
It's a boolean thing. Starring repeatedly has no additional effect.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-view(1)
|
||||
* npm-whoami(1)
|
||||
* npm-adduser(1)
|
||||
21
website/node_modules/npm/doc/cli/npm-stars.md
generated
vendored
Normal file
21
website/node_modules/npm/doc/cli/npm-stars.md
generated
vendored
Normal file
@@ -0,0 +1,21 @@
|
||||
npm-stars(1) -- View packages marked as favorites
|
||||
=================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm stars [<user>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
If you have starred a lot of neat things and want to find them again
|
||||
quickly this command lets you do just that.
|
||||
|
||||
You may also want to see your friend's favorite packages, in this case
|
||||
you will most certainly enjoy this command.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-star(1)
|
||||
* npm-view(1)
|
||||
* npm-whoami(1)
|
||||
* npm-adduser(1)
|
||||
24
website/node_modules/npm/doc/cli/npm-start.md
generated
vendored
Normal file
24
website/node_modules/npm/doc/cli/npm-start.md
generated
vendored
Normal file
@@ -0,0 +1,24 @@
|
||||
npm-start(1) -- Start a package
|
||||
===============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm start [-- <args>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This runs an arbitrary command specified in the package's `"start"` property of
|
||||
its `"scripts"` object. If no `"start"` property is specified on the
|
||||
`"scripts"` object, it will run `node server.js`.
|
||||
|
||||
As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
|
||||
use custom arguments when executing scripts. Refer to npm-run-script(1) for
|
||||
more details.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-run-script(1)
|
||||
* npm-scripts(7)
|
||||
* npm-test(1)
|
||||
* npm-restart(1)
|
||||
* npm-stop(1)
|
||||
18
website/node_modules/npm/doc/cli/npm-stop.md
generated
vendored
Normal file
18
website/node_modules/npm/doc/cli/npm-stop.md
generated
vendored
Normal file
@@ -0,0 +1,18 @@
|
||||
npm-stop(1) -- Stop a package
|
||||
=============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm stop [-- <args>]
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This runs a package's "stop" script, if one was provided.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-run-script(1)
|
||||
* npm-scripts(7)
|
||||
* npm-test(1)
|
||||
* npm-start(1)
|
||||
* npm-restart(1)
|
||||
58
website/node_modules/npm/doc/cli/npm-team.md
generated
vendored
Normal file
58
website/node_modules/npm/doc/cli/npm-team.md
generated
vendored
Normal file
@@ -0,0 +1,58 @@
|
||||
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 belong 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.
|
||||
|
||||
* edit:
|
||||
Edit a current 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-registry(7)
|
||||
20
website/node_modules/npm/doc/cli/npm-test.md
generated
vendored
Normal file
20
website/node_modules/npm/doc/cli/npm-test.md
generated
vendored
Normal file
@@ -0,0 +1,20 @@
|
||||
npm-test(1) -- Test a package
|
||||
=============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm test [-- <args>]
|
||||
|
||||
aliases: t, tst
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This runs a package's "test" script, if one was provided.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-run-script(1)
|
||||
* npm-scripts(7)
|
||||
* npm-start(1)
|
||||
* npm-restart(1)
|
||||
* npm-stop(1)
|
||||
59
website/node_modules/npm/doc/cli/npm-token.md
generated
vendored
Normal file
59
website/node_modules/npm/doc/cli/npm-token.md
generated
vendored
Normal file
@@ -0,0 +1,59 @@
|
||||
npm-token(1) -- Manage your authentication tokens
|
||||
=================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm token list [--json|--parseable]
|
||||
npm token create [--read-only] [--cidr=1.1.1.1/24,2.2.2.2/16]
|
||||
npm token revoke <id|token>
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This list you list, create and revoke authentication tokens.
|
||||
|
||||
* `npm token list`:
|
||||
Shows a table of all active authentication tokens. You can request this as
|
||||
JSON with `--json` or tab-separated values with `--parseable`.
|
||||
```
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| id | token | created | read-only | CIDR whitelist |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| 7f3134 | 1fa9ba… | 2017-10-02 | yes | |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| c03241 | af7aef… | 2017-10-02 | no | 192.168.0.1/24 |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| e0cf92 | 3a436a… | 2017-10-02 | no | |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| 63eb9d | 74ef35… | 2017-09-28 | no | |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| 2daaa8 | cbad5f… | 2017-09-26 | no | |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| 68c2fe | 127e51… | 2017-09-23 | no | |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
| 6334e1 | 1dadd1… | 2017-09-23 | no | |
|
||||
+--------+---------+------------+----------+----------------+
|
||||
```
|
||||
|
||||
* `npm token create [--read-only] [--cidr=<cidr-ranges>]`:
|
||||
Create a new authentication token. It can be `--read-only` or accept a list of
|
||||
[CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges to
|
||||
limit use of this token to. This will prompt you for your password, and, if you have
|
||||
two-factor authentication enabled, an otp.
|
||||
|
||||
```
|
||||
+----------------+--------------------------------------+
|
||||
| token | a73c9572-f1b9-8983-983d-ba3ac3cc913d |
|
||||
+----------------+--------------------------------------+
|
||||
| cidr_whitelist | |
|
||||
+----------------+--------------------------------------+
|
||||
| readonly | false |
|
||||
+----------------+--------------------------------------+
|
||||
| created | 2017-10-02T07:52:24.838Z |
|
||||
+----------------+--------------------------------------+
|
||||
```
|
||||
|
||||
* `npm token revoke <token|id>`:
|
||||
This removes an authentication token, making it immediately unusable. This can accept
|
||||
both complete tokens (as you get back from `npm token create` and will
|
||||
find in your `.npmrc`) and ids as seen in the `npm token list` output.
|
||||
This will NOT accept the truncated token found in `npm token list` output.
|
||||
53
website/node_modules/npm/doc/cli/npm-uninstall.md
generated
vendored
Normal file
53
website/node_modules/npm/doc/cli/npm-uninstall.md
generated
vendored
Normal file
@@ -0,0 +1,53 @@
|
||||
npm-uninstall(1) -- Remove a package
|
||||
=============================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm uninstall [<@scope>/]<pkg>[@<version>]... [-S|--save|-D|--save-dev|-O|--save-optional|--no-save]
|
||||
|
||||
aliases: remove, rm, r, un, unlink
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This uninstalls a package, completely removing everything npm installed
|
||||
on its behalf.
|
||||
|
||||
Example:
|
||||
|
||||
npm uninstall sax
|
||||
|
||||
In global mode (ie, with `-g` or `--global` appended to the command),
|
||||
it uninstalls the current package context as a global package.
|
||||
|
||||
`npm uninstall` takes 3 exclusive, optional flags which save or update
|
||||
the package version in your main package.json:
|
||||
|
||||
* `-S, --save`: Package will be removed from your `dependencies`.
|
||||
|
||||
* `-D, --save-dev`: Package will be removed from your `devDependencies`.
|
||||
|
||||
* `-O, --save-optional`: Package will be removed from your `optionalDependencies`.
|
||||
|
||||
* `--no-save`: Package will not be removed from your `package.json` file.
|
||||
|
||||
Further, if you have an `npm-shrinkwrap.json` then it will be updated as
|
||||
well.
|
||||
|
||||
Scope is optional and follows the usual rules for `npm-scope(7)`.
|
||||
|
||||
Examples:
|
||||
|
||||
npm uninstall sax --save
|
||||
npm uninstall @myorg/privatepackage --save
|
||||
npm uninstall node-tap --save-dev
|
||||
npm uninstall dtrace-provider --save-optional
|
||||
npm uninstall lodash --no-save
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-prune(1)
|
||||
* npm-install(1)
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
45
website/node_modules/npm/doc/cli/npm-unpublish.md
generated
vendored
Normal file
45
website/node_modules/npm/doc/cli/npm-unpublish.md
generated
vendored
Normal file
@@ -0,0 +1,45 @@
|
||||
npm-unpublish(1) -- Remove a package from the registry
|
||||
======================================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm unpublish [<@scope>/]<pkg>[@<version>]
|
||||
|
||||
## WARNING
|
||||
|
||||
**It is generally considered bad behavior to remove versions of a library
|
||||
that others are depending on!**
|
||||
|
||||
Consider using the `deprecate` command
|
||||
instead, if your intent is to encourage users to upgrade.
|
||||
|
||||
There is plenty of room on the registry.
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This removes a package version from the registry, deleting its
|
||||
entry and removing the tarball.
|
||||
|
||||
If no version is specified, or if all versions are removed then
|
||||
the root package entry is removed from the registry entirely.
|
||||
|
||||
Even if a package version is unpublished, that specific name and
|
||||
version combination can never be reused. In order to publish the
|
||||
package again, a new version number must be used. Additionally,
|
||||
new versions of packages with every version unpublished may not
|
||||
be republished until 24 hours have passed.
|
||||
|
||||
With the default registry (`registry.npmjs.org`), unpublish is
|
||||
only allowed with versions published in the last 72 hours. If you
|
||||
are trying to unpublish a version published longer ago than that,
|
||||
contact support@npmjs.com.
|
||||
|
||||
The scope is optional and follows the usual rules for `npm-scope(7)`.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-deprecate(1)
|
||||
* npm-publish(1)
|
||||
* npm-registry(7)
|
||||
* npm-adduser(1)
|
||||
* npm-owner(1)
|
||||
129
website/node_modules/npm/doc/cli/npm-update.md
generated
vendored
Normal file
129
website/node_modules/npm/doc/cli/npm-update.md
generated
vendored
Normal file
@@ -0,0 +1,129 @@
|
||||
npm-update(1) -- Update a package
|
||||
=================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm update [-g] [<pkg>...]
|
||||
|
||||
aliases: up, upgrade
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This command will update all the packages listed to the latest version
|
||||
(specified by the `tag` config), respecting semver.
|
||||
|
||||
It will also install missing packages. As with all commands that install
|
||||
packages, the `--dev` flag will cause `devDependencies` to be processed
|
||||
as well.
|
||||
|
||||
If the `-g` flag is specified, this command will update globally installed
|
||||
packages.
|
||||
|
||||
If no package name is specified, all packages in the specified location (global
|
||||
or local) will be updated.
|
||||
|
||||
As of `npm@2.6.1`, the `npm update` will only inspect top-level packages.
|
||||
Prior versions of `npm` would also recursively inspect all dependencies.
|
||||
To get the old behavior, use `npm --depth 9999 update`.
|
||||
|
||||
As of `npm@5.0.0`, the `npm update` will change `package.json` to save the
|
||||
new version as the minimum required dependency. To get the old behavior,
|
||||
use `npm update --no-save`.
|
||||
|
||||
## EXAMPLES
|
||||
|
||||
IMPORTANT VERSION NOTE: these examples assume `npm@2.6.1` or later. For
|
||||
older versions of `npm`, you must specify `--depth 0` to get the behavior
|
||||
described below.
|
||||
|
||||
For the examples below, assume that the current package is `app` and it depends
|
||||
on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` are:
|
||||
|
||||
```
|
||||
{
|
||||
"dist-tags": { "latest": "1.2.2" },
|
||||
"versions": [
|
||||
"1.2.2",
|
||||
"1.2.1",
|
||||
"1.2.0",
|
||||
"1.1.2",
|
||||
"1.1.1",
|
||||
"1.0.0",
|
||||
"0.4.1",
|
||||
"0.4.0",
|
||||
"0.2.0"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Caret Dependencies
|
||||
|
||||
If `app`'s `package.json` contains:
|
||||
|
||||
```
|
||||
"dependencies": {
|
||||
"dep1": "^1.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
Then `npm update` will install `dep1@1.2.2`, because `1.2.2` is `latest` and
|
||||
`1.2.2` satisfies `^1.1.1`.
|
||||
|
||||
### Tilde Dependencies
|
||||
|
||||
However, if `app`'s `package.json` contains:
|
||||
|
||||
```
|
||||
"dependencies": {
|
||||
"dep1": "~1.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
In this case, running `npm update` will install `dep1@1.1.2`. Even though the `latest`
|
||||
tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivalent
|
||||
to `>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies `~1.1.1` is used,
|
||||
which is `1.1.2`.
|
||||
|
||||
### Caret Dependencies below 1.0.0
|
||||
|
||||
Suppose `app` has a caret dependency on a version below `1.0.0`, for example:
|
||||
|
||||
```
|
||||
"dependencies": {
|
||||
"dep1": "^0.2.0"
|
||||
}
|
||||
```
|
||||
|
||||
`npm update` will install `dep1@0.2.0`, because there are no other
|
||||
versions which satisfy `^0.2.0`.
|
||||
|
||||
If the dependence were on `^0.4.0`:
|
||||
|
||||
```
|
||||
"dependencies": {
|
||||
"dep1": "^0.4.0"
|
||||
}
|
||||
```
|
||||
|
||||
Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting
|
||||
version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`)
|
||||
|
||||
|
||||
### Updating Globally-Installed Packages
|
||||
|
||||
`npm update -g` will apply the `update` action to each globally installed
|
||||
package that is `outdated` -- that is, has a version that is different from
|
||||
`latest`.
|
||||
|
||||
NOTE: If a package has been upgraded to a version newer than `latest`, it will
|
||||
be _downgraded_.
|
||||
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-install(1)
|
||||
* npm-outdated(1)
|
||||
* npm-shrinkwrap(1)
|
||||
* npm-registry(7)
|
||||
* npm-folders(5)
|
||||
* npm-ls(1)
|
||||
119
website/node_modules/npm/doc/cli/npm-version.md
generated
vendored
Normal file
119
website/node_modules/npm/doc/cli/npm-version.md
generated
vendored
Normal file
@@ -0,0 +1,119 @@
|
||||
npm-version(1) -- Bump a package version
|
||||
========================================
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | 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`, `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 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)
|
||||
96
website/node_modules/npm/doc/cli/npm-view.md
generated
vendored
Normal file
96
website/node_modules/npm/doc/cli/npm-view.md
generated
vendored
Normal file
@@ -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)
|
||||
17
website/node_modules/npm/doc/cli/npm-whoami.md
generated
vendored
Normal file
17
website/node_modules/npm/doc/cli/npm-whoami.md
generated
vendored
Normal file
@@ -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)
|
||||
165
website/node_modules/npm/doc/cli/npm.md
generated
vendored
Normal file
165
website/node_modules/npm/doc/cli/npm.md
generated
vendored
Normal file
@@ -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.
|
||||
|
||||
## IMPORTANT
|
||||
|
||||
npm is configured to use npm, Inc.'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://www.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 may be governed by their
|
||||
terms of use.
|
||||
|
||||
## 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!
|
||||
|
||||
If you would like to contribute, but don't know what to work on, read
|
||||
the contributing guidelines and check the issues list.
|
||||
|
||||
* [CONTRIBUTING.md](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md)
|
||||
* [Bug tracker](https://npm.community/c/bugs)
|
||||
* [Support tracker](https://npm.community/c/support)
|
||||
|
||||
## BUGS
|
||||
|
||||
When you find issues, please report them:
|
||||
|
||||
* web:
|
||||
<https://npm.community/c/bugs>
|
||||
|
||||
Be sure to follow the template and bug reporting guidelines. You can also ask
|
||||
for help in the [support forum](https://npm.community/c/support) if you're
|
||||
unsure if it's actually a bug or are having trouble coming up with a detailed
|
||||
reproduction to report.
|
||||
|
||||
## AUTHOR
|
||||
|
||||
[Isaac Z. Schlueter](http://blog.izs.me/) ::
|
||||
[isaacs](https://github.com/isaacs/) ::
|
||||
[@izs](https://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)
|
||||
213
website/node_modules/npm/doc/files/npm-folders.md
generated
vendored
Normal file
213
website/node_modules/npm/doc/files/npm-folders.md
generated
vendored
Normal file
@@ -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
|
||||
`%AppData%/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)
|
||||
164
website/node_modules/npm/doc/files/npm-package-locks.md
generated
vendored
Normal file
164
website/node_modules/npm/doc/files/npm-package-locks.md
generated
vendored
Normal file
@@ -0,0 +1,164 @@
|
||||
npm-package-locks(5) -- An explanation of npm lockfiles
|
||||
=====================================================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Conceptually, the "input" to npm-install(1) is a package.json(5), while its
|
||||
"output" is a fully-formed `node_modules` tree: a representation of the
|
||||
dependencies you declared. In an ideal world, npm would work like a pure
|
||||
function: the same `package.json` should produce the exact same `node_modules`
|
||||
tree, any time. In some cases, this is indeed true. But in many others, npm is
|
||||
unable to do this. There are multiple reasons for this:
|
||||
|
||||
* different versions of npm (or other package managers) may have been used to install a package, each using slightly different installation algorithms.
|
||||
|
||||
* a new version of a direct semver-range package may have been published since the last time your packages were installed, and thus a newer version will be used.
|
||||
|
||||
* A dependency of one of your dependencies may have published a new version, which will update even if you used pinned dependency specifiers (`1.2.3` instead of `^1.2.3`)
|
||||
|
||||
* The registry you installed from is no longer available, or allows mutation of versions (unlike the primary npm registry), and a different version of a package exists under the same version number now.
|
||||
|
||||
As an example, consider package A:
|
||||
|
||||
{
|
||||
"name": "A",
|
||||
"version": "0.1.0",
|
||||
"dependencies": {
|
||||
"B": "<0.1.0"
|
||||
}
|
||||
}
|
||||
|
||||
package B:
|
||||
|
||||
{
|
||||
"name": "B",
|
||||
"version": "0.0.1",
|
||||
"dependencies": {
|
||||
"C": "<0.1.0"
|
||||
}
|
||||
}
|
||||
|
||||
and package C:
|
||||
|
||||
{
|
||||
"name": "C",
|
||||
"version": "0.0.1"
|
||||
}
|
||||
|
||||
If these are the only versions of A, B, and C available in the
|
||||
registry, then a normal `npm install A` will install:
|
||||
|
||||
A@0.1.0
|
||||
`-- B@0.0.1
|
||||
`-- C@0.0.1
|
||||
|
||||
However, if B@0.0.2 is published, then a fresh `npm install A` will
|
||||
install:
|
||||
|
||||
A@0.1.0
|
||||
`-- B@0.0.2
|
||||
`-- C@0.0.1
|
||||
|
||||
assuming the new version did not modify B's dependencies. Of course,
|
||||
the new version of B could include a new version of C and any number
|
||||
of new dependencies. If such changes are undesirable, the author of A
|
||||
could specify a dependency on B@0.0.1. However, if A's author and B's
|
||||
author are not the same person, there's no way for A's author to say
|
||||
that he or she does not want to pull in newly published versions of C
|
||||
when B hasn't changed at all.
|
||||
|
||||
To prevent this potential issue, npm uses package-lock.json(5) or, if present,
|
||||
npm-shrinkwrap.json(5). These files are called package locks, or lockfiles.
|
||||
|
||||
Whenever you run `npm install`, npm generates or updates your package lock,
|
||||
which will look something like this:
|
||||
|
||||
{
|
||||
"name": "A",
|
||||
"version": "0.1.0",
|
||||
...metadata fields...
|
||||
"dependencies": {
|
||||
"B": {
|
||||
"version": "0.0.1",
|
||||
"resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz",
|
||||
"integrity": "sha512-DeAdb33F+"
|
||||
"dependencies": {
|
||||
"C": {
|
||||
"version": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
This file describes an *exact*, and more importantly *reproducible*
|
||||
`node_modules` tree. Once it's present, any future installation will base its
|
||||
work off this file, instead of recalculating dependency versions off
|
||||
package.json(5).
|
||||
|
||||
The presence of a package lock changes the installation behavior such that:
|
||||
|
||||
1. The module tree described by the package lock is reproduced. This means
|
||||
reproducing the structure described in the file, using the specific files
|
||||
referenced in "resolved" if available, falling back to normal package resolution
|
||||
using "version" if one isn't.
|
||||
|
||||
2. The tree is walked and any missing dependencies are installed in the usual
|
||||
fashion.
|
||||
|
||||
If `preshrinkwrap`, `shrinkwrap` or `postshrinkwrap` are in the `scripts`
|
||||
property of the `package.json`, they will be executed in order. `preshrinkwrap`
|
||||
and `shrinkwrap` are executed before the shrinkwrap, `postshrinkwrap` is
|
||||
executed afterwards. These scripts run for both `package-lock.json` and
|
||||
`npm-shrinkwrap.json`. For example to run some postprocessing on the generated
|
||||
file:
|
||||
|
||||
"scripts": {
|
||||
"postshrinkwrap": "json -I -e \"this.myMetadata = $MY_APP_METADATA\""
|
||||
}
|
||||
|
||||
|
||||
### Using locked packages
|
||||
|
||||
Using a locked package is no different than using any package without a package
|
||||
lock: any commands that update `node_modules` and/or `package.json`'s
|
||||
dependencies will automatically sync the existing lockfile. This includes `npm
|
||||
install`, `npm rm`, `npm update`, etc. To prevent this update from happening,
|
||||
you can use the `--no-save` option to prevent saving altogether, or
|
||||
`--no-shrinkwrap` to allow `package.json` to be updated while leaving
|
||||
`package-lock.json` or `npm-shrinkwrap.json` intact.
|
||||
|
||||
It is highly recommended you commit the generated package lock to source
|
||||
control: this will allow anyone else on your team, your deployments, your
|
||||
CI/continuous integration, and anyone else who runs `npm install` in your
|
||||
package source to get the exact same dependency tree that you were developing
|
||||
on. Additionally, the diffs from these changes are human-readable and will
|
||||
inform you of any changes npm has made to your `node_modules`, so you can notice
|
||||
if any transitive dependencies were updated, hoisted, etc.
|
||||
|
||||
### Resolving lockfile conflicts
|
||||
|
||||
Occasionally, two separate npm install will create package locks that cause
|
||||
merge conflicts in source control systems. As of `npm@5.7.0`, these conflicts
|
||||
can be resolved by manually fixing any `package.json` conflicts, and then
|
||||
running `npm install [--package-lock-only]` again. npm will automatically
|
||||
resolve any conflicts for you and write a merged package lock that includes all
|
||||
the dependencies from both branches in a reasonable tree. If
|
||||
`--package-lock-only` is provided, it will do this without also modifying your
|
||||
local `node_modules/`.
|
||||
|
||||
To make this process seamless on git, consider installing
|
||||
[`npm-merge-driver`](https://npm.im/npm-merge-driver), which will teach git how
|
||||
to do this itself without any user interaction. In short: `$ npx
|
||||
npm-merge-driver install -g` will let you do this, and even works with
|
||||
pre-`npm@5.7.0` versions of npm 5, albeit a bit more noisily. Note that if
|
||||
`package.json` itself conflicts, you will have to resolve that by hand and run
|
||||
`npm install` manually, even with the merge driver.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527
|
||||
* package.json(5)
|
||||
* package-lock.json(5)
|
||||
* npm-shrinkwrap.json(5)
|
||||
* npm-shrinkwrap(1)
|
||||
27
website/node_modules/npm/doc/files/npm-shrinkwrap.json.md
generated
vendored
Normal file
27
website/node_modules/npm/doc/files/npm-shrinkwrap.json.md
generated
vendored
Normal file
@@ -0,0 +1,27 @@
|
||||
npm-shrinkwrap.json(5) -- A publishable lockfile
|
||||
=====================================================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
`npm-shrinkwrap.json` is a file created by npm-shrinkwrap(1). It is identical to
|
||||
`package-lock.json`, with one major caveat: Unlike `package-lock.json`,
|
||||
`npm-shrinkwrap.json` may be included when publishing a package.
|
||||
|
||||
The recommended use-case for `npm-shrinkwrap.json` is applications deployed
|
||||
through the publishing process on the registry: for example, daemons and
|
||||
command-line tools intended as global installs or `devDependencies`. It's
|
||||
strongly discouraged for library authors to publish this file, since that would
|
||||
prevent end users from having control over transitive dependency updates.
|
||||
|
||||
Additionally, if both `package-lock.json` and `npm-shrinkwrap.json` are present
|
||||
in a package root, `package-lock.json` will be ignored in favor of this file.
|
||||
|
||||
For full details and description of the `npm-shrinkwrap.json` file format, refer
|
||||
to the manual page for package-lock.json(5).
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-shrinkwrap(1)
|
||||
* package-lock.json(5)
|
||||
* package.json(5)
|
||||
* npm-install(1)
|
||||
90
website/node_modules/npm/doc/files/npmrc.md
generated
vendored
Normal file
90
website/node_modules/npm/doc/files/npmrc.md
generated
vendored
Normal file
@@ -0,0 +1,90 @@
|
||||
npmrc(5) -- The npm config files
|
||||
================================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
npm gets its config settings from the command line, environment
|
||||
variables, and `npmrc` files.
|
||||
|
||||
The `npm config` command can be used to update and edit the contents
|
||||
of the user and global npmrc files.
|
||||
|
||||
For a list of available configuration options, see npm-config(7).
|
||||
|
||||
## FILES
|
||||
|
||||
The four relevant files are:
|
||||
|
||||
* per-project config file (/path/to/my/project/.npmrc)
|
||||
* per-user config file (~/.npmrc)
|
||||
* global config file ($PREFIX/etc/npmrc)
|
||||
* npm builtin config file (/path/to/npm/npmrc)
|
||||
|
||||
All npm config files are an ini-formatted list of `key = value`
|
||||
parameters. Environment variables can be replaced using
|
||||
`${VARIABLE_NAME}`. For example:
|
||||
|
||||
prefix = ${HOME}/.npm-packages
|
||||
|
||||
Each of these files is loaded, and config options are resolved in
|
||||
priority order. For example, a setting in the userconfig file would
|
||||
override the setting in the globalconfig file.
|
||||
|
||||
Array values are specified by adding "[]" after the key name. For
|
||||
example:
|
||||
|
||||
key[] = "first value"
|
||||
key[] = "second value"
|
||||
|
||||
#### Comments
|
||||
|
||||
Lines in `.npmrc` files are interpreted as comments when they begin with a `;` or `#` character. `.npmrc` files are parsed by [npm/ini](https://github.com/npm/ini), which specifies this comment syntax.
|
||||
|
||||
For example:
|
||||
|
||||
# last modified: 01 Jan 2016
|
||||
; Set a new registry for a scoped package
|
||||
@myscope:registry=https://mycustomregistry.example.org
|
||||
|
||||
### Per-project config file
|
||||
|
||||
When working locally in a project, a `.npmrc` file in the root of the
|
||||
project (ie, a sibling of `node_modules` and `package.json`) will set
|
||||
config values specific to this project.
|
||||
|
||||
Note that this only applies to the root of the project that you're
|
||||
running npm in. It has no effect when your module is published. For
|
||||
example, you can't publish a module that forces itself to install
|
||||
globally, or in a different location.
|
||||
|
||||
Additionally, this file is not read in global mode, such as when running
|
||||
`npm install -g`.
|
||||
|
||||
### Per-user config file
|
||||
|
||||
`$HOME/.npmrc` (or the `userconfig` param, if set in the environment
|
||||
or on the command line)
|
||||
|
||||
### Global config file
|
||||
|
||||
`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above):
|
||||
This file is an ini-file formatted list of `key = value` parameters.
|
||||
Environment variables can be replaced as above.
|
||||
|
||||
### Built-in config file
|
||||
|
||||
`path/to/npm/itself/npmrc`
|
||||
|
||||
This is an unchangeable "builtin" configuration file that npm keeps
|
||||
consistent across updates. Set fields in here using the `./configure`
|
||||
script that comes with npm. This is primarily for distribution
|
||||
maintainers to override default configs in a standard and consistent
|
||||
manner.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-folders(5)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* package.json(5)
|
||||
* npm(1)
|
||||
142
website/node_modules/npm/doc/files/package-lock.json.md
generated
vendored
Normal file
142
website/node_modules/npm/doc/files/package-lock.json.md
generated
vendored
Normal file
@@ -0,0 +1,142 @@
|
||||
package-lock.json(5) -- A manifestation of the manifest
|
||||
=====================================================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
`package-lock.json` is automatically generated for any operations where npm
|
||||
modifies either the `node_modules` tree, or `package.json`. It describes the
|
||||
exact tree that was generated, such that subsequent installs are able to
|
||||
generate identical trees, regardless of intermediate dependency updates.
|
||||
|
||||
This file is intended to be committed into source repositories, and serves
|
||||
various purposes:
|
||||
|
||||
* Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
|
||||
|
||||
* Provide a facility for users to "time-travel" to previous states of `node_modules` without having to commit the directory itself.
|
||||
|
||||
* To facilitate greater visibility of tree changes through readable source control diffs.
|
||||
|
||||
* And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
|
||||
|
||||
One key detail about `package-lock.json` is that it cannot be published, and it
|
||||
will be ignored if found in any place other than the toplevel package. It shares
|
||||
a format with npm-shrinkwrap.json(5), which is essentially the same file, but
|
||||
allows publication. This is not recommended unless deploying a CLI tool or
|
||||
otherwise using the publication process for producing production packages.
|
||||
|
||||
If both `package-lock.json` and `npm-shrinkwrap.json` are present in the root of
|
||||
a package, `package-lock.json` will be completely ignored.
|
||||
|
||||
|
||||
## FILE FORMAT
|
||||
|
||||
### name
|
||||
|
||||
The name of the package this is a package-lock for. This must match what's in
|
||||
`package.json`.
|
||||
|
||||
### version
|
||||
|
||||
The version of the package this is a package-lock for. This must match what's in
|
||||
`package.json`.
|
||||
|
||||
### lockfileVersion
|
||||
|
||||
An integer version, starting at `1` with the version number of this document
|
||||
whose semantics were used when generating this `package-lock.json`.
|
||||
|
||||
### packageIntegrity
|
||||
|
||||
This is a [subresource
|
||||
integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) value
|
||||
created from the `package.json`. No preprocessing of the `package.json` should
|
||||
be done. Subresource integrity strings can be produced by modules like
|
||||
[`ssri`](https://www.npmjs.com/package/ssri).
|
||||
|
||||
### preserveSymlinks
|
||||
|
||||
Indicates that the install was done with the environment variable
|
||||
`NODE_PRESERVE_SYMLINKS` enabled. The installer should insist that the value of
|
||||
this property match that environment variable.
|
||||
|
||||
### dependencies
|
||||
|
||||
A mapping of package name to dependency object. Dependency objects have the
|
||||
following properties:
|
||||
|
||||
#### version
|
||||
|
||||
This is a specifier that uniquely identifies this package and should be
|
||||
usable in fetching a new copy of it.
|
||||
|
||||
* bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
|
||||
* registry sources: This is a version number. (eg, `1.2.3`)
|
||||
* git sources: This is a git specifier with resolved committish. (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`)
|
||||
* http tarball sources: This is the URL of the tarball. (eg, `https://example.com/example-1.3.0.tgz`)
|
||||
* local tarball sources: This is the file URL of the tarball. (eg `file:///opt/storage/example-1.3.0.tgz`)
|
||||
* local link sources: This is the file URL of the link. (eg `file:libs/our-module`)
|
||||
|
||||
#### integrity
|
||||
|
||||
This is a [Standard Subresource
|
||||
Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) for this
|
||||
resource.
|
||||
|
||||
* For bundled dependencies this is not included, regardless of source.
|
||||
* For registry sources, this is the `integrity` that the registry provided, or if one wasn't provided the SHA1 in `shasum`.
|
||||
* For git sources this is the specific commit hash we cloned from.
|
||||
* For remote tarball sources this is an integrity based on a SHA512 of
|
||||
the file.
|
||||
* For local tarball sources: This is an integrity field based on the SHA512 of the file.
|
||||
|
||||
#### resolved
|
||||
|
||||
* For bundled dependencies this is not included, regardless of source.
|
||||
* For registry sources this is path of the tarball relative to the registry
|
||||
URL. If the tarball URL isn't on the same server as the registry URL then
|
||||
this is a complete URL.
|
||||
|
||||
#### bundled
|
||||
|
||||
If true, this is the bundled dependency and will be installed by the parent
|
||||
module. When installing, this module will be extracted from the parent
|
||||
module during the extract phase, not installed as a separate dependency.
|
||||
|
||||
#### dev
|
||||
|
||||
If true then this dependency is either a development dependency ONLY of the
|
||||
top level module or a transitive dependency of one. This is false for
|
||||
dependencies that are both a development dependency of the top level and a
|
||||
transitive dependency of a non-development dependency of the top level.
|
||||
|
||||
#### optional
|
||||
|
||||
If true then this dependency is either an optional dependency ONLY of the
|
||||
top level module or a transitive dependency of one. This is false for
|
||||
dependencies that are both an optional dependency of the top level and a
|
||||
transitive dependency of a non-optional dependency of the top level.
|
||||
|
||||
All optional dependencies should be included even if they're uninstallable
|
||||
on the current platform.
|
||||
|
||||
|
||||
#### requires
|
||||
|
||||
This is a mapping of module name to version. This is a list of everything
|
||||
this module requires, regardless of where it will be installed. The version
|
||||
should match via normal matching rules a dependency either in our
|
||||
`dependencies` or in a level higher than us.
|
||||
|
||||
|
||||
#### dependencies
|
||||
|
||||
The dependencies of this dependency, exactly as at the top level.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-shrinkwrap(1)
|
||||
* npm-shrinkwrap.json(5)
|
||||
* npm-package-locks(5)
|
||||
* package.json(5)
|
||||
* npm-install(1)
|
||||
797
website/node_modules/npm/doc/files/package.json.md
generated
vendored
Normal file
797
website/node_modules/npm/doc/files/package.json.md
generated
vendored
Normal file
@@ -0,0 +1,797 @@
|
||||
package.json(5) -- Specifics of npm's package.json handling
|
||||
===========================================================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This document is all you need to know about what's required in your package.json
|
||||
file. It must be actual JSON, not just a JavaScript object literal.
|
||||
|
||||
A lot of the behavior described in this document is affected by the config
|
||||
settings described in `npm-config(7)`.
|
||||
|
||||
## name
|
||||
|
||||
If you plan to publish your package, the *most* important things in your
|
||||
package.json are the name and version fields as they will be required. The name
|
||||
and version together form an identifier that is assumed to be completely unique.
|
||||
Changes to the package should come along with changes to the version. If you don't
|
||||
plan to publish your package, the name and version fields are optional.
|
||||
|
||||
The name is what your thing is called.
|
||||
|
||||
Some rules:
|
||||
|
||||
* The name must be less than or equal to 214 characters. This includes the scope for
|
||||
scoped packages.
|
||||
* The name can't start with a dot or an underscore.
|
||||
* New packages must not have uppercase letters in the name.
|
||||
* The name ends up being part of a URL, an argument on the command line, and a
|
||||
folder name. Therefore, the name can't contain any non-URL-safe characters.
|
||||
|
||||
Some tips:
|
||||
|
||||
* Don't use the same name as a core Node module.
|
||||
* Don't put "js" or "node" in the name. It's assumed that it's js, since you're
|
||||
writing a package.json file, and you can specify the engine using the "engines"
|
||||
field. (See below.)
|
||||
* The name will probably be passed as an argument to require(), so it should
|
||||
be something short, but also reasonably descriptive.
|
||||
* You may want to check the npm registry to see if there's something by that name
|
||||
already, before you get too attached to it. <https://www.npmjs.com/>
|
||||
|
||||
A name can be optionally prefixed by a scope, e.g. `@myorg/mypackage`. See
|
||||
`npm-scope(7)` for more detail.
|
||||
|
||||
## version
|
||||
|
||||
If you plan to publish your package, the *most* important things in your
|
||||
package.json are the name and version fields as they will be required. The name
|
||||
and version together form an identifier that is assumed to be completely unique.
|
||||
Changes to the package should come along with changes to the version. If you don't
|
||||
plan to publish your package, the name and version fields are optional.
|
||||
|
||||
Version must be parseable by
|
||||
[node-semver](https://github.com/isaacs/node-semver), which is bundled
|
||||
with npm as a dependency. (`npm install semver` to use it yourself.)
|
||||
|
||||
More on version numbers and ranges at semver(7).
|
||||
|
||||
## description
|
||||
|
||||
Put a description in it. It's a string. This helps people discover your
|
||||
package, as it's listed in `npm search`.
|
||||
|
||||
## keywords
|
||||
|
||||
Put keywords in it. It's an array of strings. This helps people
|
||||
discover your package as it's listed in `npm search`.
|
||||
|
||||
## homepage
|
||||
|
||||
The url to the project homepage.
|
||||
|
||||
Example:
|
||||
|
||||
"homepage": "https://github.com/owner/project#readme"
|
||||
|
||||
## bugs
|
||||
|
||||
The url to your project's issue tracker and / or the email address to which
|
||||
issues should be reported. These are helpful for people who encounter issues
|
||||
with your package.
|
||||
|
||||
It should look like this:
|
||||
|
||||
{ "url" : "https://github.com/owner/project/issues"
|
||||
, "email" : "project@hostname.com"
|
||||
}
|
||||
|
||||
You can specify either one or both values. If you want to provide only a url,
|
||||
you can specify the value for "bugs" as a simple string instead of an object.
|
||||
|
||||
If a url is provided, it will be used by the `npm bugs` command.
|
||||
|
||||
## license
|
||||
|
||||
You should specify a license for your package so that people know how they are
|
||||
permitted to use it, and any restrictions you're placing on it.
|
||||
|
||||
If you're using a common license such as BSD-2-Clause or MIT, add a
|
||||
current SPDX license identifier for the license you're using, like this:
|
||||
|
||||
{ "license" : "BSD-3-Clause" }
|
||||
|
||||
You can check [the full list of SPDX license IDs](https://spdx.org/licenses/).
|
||||
Ideally you should pick one that is
|
||||
[OSI](https://opensource.org/licenses/alphabetical) approved.
|
||||
|
||||
If your package is licensed under multiple common licenses, use an [SPDX license
|
||||
expression syntax version 2.0 string](https://www.npmjs.com/package/spdx), like this:
|
||||
|
||||
{ "license" : "(ISC OR GPL-3.0)" }
|
||||
|
||||
If you are using a license that hasn't been assigned an SPDX identifier, or if
|
||||
you are using a custom license, use a string value like this one:
|
||||
|
||||
{ "license" : "SEE LICENSE IN <filename>" }
|
||||
|
||||
Then include a file named `<filename>` at the top level of the package.
|
||||
|
||||
Some old packages used license objects or a "licenses" property containing an
|
||||
array of license objects:
|
||||
|
||||
// Not valid metadata
|
||||
{ "license" :
|
||||
{ "type" : "ISC"
|
||||
, "url" : "https://opensource.org/licenses/ISC"
|
||||
}
|
||||
}
|
||||
|
||||
// Not valid metadata
|
||||
{ "licenses" :
|
||||
[
|
||||
{ "type": "MIT"
|
||||
, "url": "https://www.opensource.org/licenses/mit-license.php"
|
||||
}
|
||||
, { "type": "Apache-2.0"
|
||||
, "url": "https://opensource.org/licenses/apache2.0.php"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
Those styles are now deprecated. Instead, use SPDX expressions, like this:
|
||||
|
||||
{ "license": "ISC" }
|
||||
|
||||
{ "license": "(MIT OR Apache-2.0)" }
|
||||
|
||||
Finally, if you do not wish to grant others the right to use a private or
|
||||
unpublished package under any terms:
|
||||
|
||||
{ "license": "UNLICENSED" }
|
||||
|
||||
Consider also setting `"private": true` to prevent accidental publication.
|
||||
|
||||
## people fields: author, contributors
|
||||
|
||||
The "author" is one person. "contributors" is an array of people. A "person"
|
||||
is an object with a "name" field and optionally "url" and "email", like this:
|
||||
|
||||
{ "name" : "Barney Rubble"
|
||||
, "email" : "b@rubble.com"
|
||||
, "url" : "http://barnyrubble.tumblr.com/"
|
||||
}
|
||||
|
||||
Or you can shorten that all into a single string, and npm will parse it for you:
|
||||
|
||||
"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
|
||||
|
||||
Both email and url are optional either way.
|
||||
|
||||
npm also sets a top-level "maintainers" field with your npm user info.
|
||||
|
||||
## files
|
||||
|
||||
The optional `files` field is an array of file patterns that describes
|
||||
the entries to be included when your package is installed as a
|
||||
dependency. File patterns follow a similar syntax to `.gitignore`, but
|
||||
reversed: including a file, directory, or glob pattern (`*`, `**/*`, and such)
|
||||
will make it so that file is included in the tarball when it's packed. Omitting
|
||||
the field will make it default to `["*"]`, which means it will include all files.
|
||||
|
||||
Some special files and directories are also included or excluded regardless of
|
||||
whether they exist in the `files` array (see below).
|
||||
|
||||
You can also provide a `.npmignore` file in the root of your package or
|
||||
in subdirectories, which will keep files from being included. At the
|
||||
root of your package it will not override the "files" field, but in
|
||||
subdirectories it will. The `.npmignore` file works just like a
|
||||
`.gitignore`. If there is a `.gitignore` file, and `.npmignore` is
|
||||
missing, `.gitignore`'s contents will be used instead.
|
||||
|
||||
Files included with the "package.json#files" field _cannot_ be excluded
|
||||
through `.npmignore` or `.gitignore`.
|
||||
|
||||
Certain files are always included, regardless of settings:
|
||||
|
||||
* `package.json`
|
||||
* `README`
|
||||
* `CHANGES` / `CHANGELOG` / `HISTORY`
|
||||
* `LICENSE` / `LICENCE`
|
||||
* `NOTICE`
|
||||
* The file in the "main" field
|
||||
|
||||
`README`, `CHANGES`, `LICENSE` & `NOTICE` can have any case and extension.
|
||||
|
||||
Conversely, some files are always ignored:
|
||||
|
||||
* `.git`
|
||||
* `CVS`
|
||||
* `.svn`
|
||||
* `.hg`
|
||||
* `.lock-wscript`
|
||||
* `.wafpickle-N`
|
||||
* `.*.swp`
|
||||
* `.DS_Store`
|
||||
* `._*`
|
||||
* `npm-debug.log`
|
||||
* `.npmrc`
|
||||
* `node_modules`
|
||||
* `config.gypi`
|
||||
* `*.orig`
|
||||
* `package-lock.json` (use shrinkwrap instead)
|
||||
|
||||
## main
|
||||
|
||||
The main field is a module ID that is the primary entry point to your program.
|
||||
That is, if your package is named `foo`, and a user installs it, and then does
|
||||
`require("foo")`, then your main module's exports object will be returned.
|
||||
|
||||
This should be a module ID relative to the root of your package folder.
|
||||
|
||||
For most modules, it makes the most sense to have a main script and often not
|
||||
much else.
|
||||
|
||||
## browser
|
||||
|
||||
If your module is meant to be used client-side the browser field should be
|
||||
used instead of the main field. This is helpful to hint users that it might
|
||||
rely on primitives that aren't available in Node.js modules. (e.g. `window`)
|
||||
|
||||
## bin
|
||||
|
||||
A lot of packages have one or more executable files that they'd like to
|
||||
install into the PATH. npm makes this pretty easy (in fact, it uses this
|
||||
feature to install the "npm" executable.)
|
||||
|
||||
To use this, supply a `bin` field in your package.json which is a map of
|
||||
command name to local file name. On install, npm will symlink that file into
|
||||
`prefix/bin` for global installs, or `./node_modules/.bin/` for local
|
||||
installs.
|
||||
|
||||
|
||||
For example, myapp could have this:
|
||||
|
||||
{ "bin" : { "myapp" : "./cli.js" } }
|
||||
|
||||
So, when you install myapp, it'll create a symlink from the `cli.js` script to
|
||||
`/usr/local/bin/myapp`.
|
||||
|
||||
If you have a single executable, and its name should be the name
|
||||
of the package, then you can just supply it as a string. For example:
|
||||
|
||||
{ "name": "my-program"
|
||||
, "version": "1.2.5"
|
||||
, "bin": "./path/to/program" }
|
||||
|
||||
would be the same as this:
|
||||
|
||||
{ "name": "my-program"
|
||||
, "version": "1.2.5"
|
||||
, "bin" : { "my-program" : "./path/to/program" } }
|
||||
|
||||
Please make sure that your file(s) referenced in `bin` starts with
|
||||
`#!/usr/bin/env node`, otherwise the scripts are started without the node
|
||||
executable!
|
||||
|
||||
## man
|
||||
|
||||
Specify either a single file or an array of filenames to put in place for the
|
||||
`man` program to find.
|
||||
|
||||
If only a single file is provided, then it's installed such that it is the
|
||||
result from `man <pkgname>`, regardless of its actual filename. For example:
|
||||
|
||||
{ "name" : "foo"
|
||||
, "version" : "1.2.3"
|
||||
, "description" : "A packaged foo fooer for fooing foos"
|
||||
, "main" : "foo.js"
|
||||
, "man" : "./man/doc.1"
|
||||
}
|
||||
|
||||
would link the `./man/doc.1` file in such that it is the target for `man foo`
|
||||
|
||||
If the filename doesn't start with the package name, then it's prefixed.
|
||||
So, this:
|
||||
|
||||
{ "name" : "foo"
|
||||
, "version" : "1.2.3"
|
||||
, "description" : "A packaged foo fooer for fooing foos"
|
||||
, "main" : "foo.js"
|
||||
, "man" : [ "./man/foo.1", "./man/bar.1" ]
|
||||
}
|
||||
|
||||
will create files to do `man foo` and `man foo-bar`.
|
||||
|
||||
Man files must end with a number, and optionally a `.gz` suffix if they are
|
||||
compressed. The number dictates which man section the file is installed into.
|
||||
|
||||
{ "name" : "foo"
|
||||
, "version" : "1.2.3"
|
||||
, "description" : "A packaged foo fooer for fooing foos"
|
||||
, "main" : "foo.js"
|
||||
, "man" : [ "./man/foo.1", "./man/foo.2" ]
|
||||
}
|
||||
|
||||
will create entries for `man foo` and `man 2 foo`
|
||||
|
||||
## directories
|
||||
|
||||
The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a
|
||||
few ways that you can indicate the structure of your package using a `directories`
|
||||
object. If you look at [npm's package.json](https://registry.npmjs.org/npm/latest),
|
||||
you'll see that it has directories for doc, lib, and man.
|
||||
|
||||
In the future, this information may be used in other creative ways.
|
||||
|
||||
### directories.lib
|
||||
|
||||
Tell people where the bulk of your library is. Nothing special is done
|
||||
with the lib folder in any way, but it's useful meta info.
|
||||
|
||||
### directories.bin
|
||||
|
||||
If you specify a `bin` directory in `directories.bin`, all the files in
|
||||
that folder will be added.
|
||||
|
||||
Because of the way the `bin` directive works, specifying both a
|
||||
`bin` path and setting `directories.bin` is an error. If you want to
|
||||
specify individual files, use `bin`, and for all the files in an
|
||||
existing `bin` directory, use `directories.bin`.
|
||||
|
||||
### directories.man
|
||||
|
||||
A folder that is full of man pages. Sugar to generate a "man" array by
|
||||
walking the folder.
|
||||
|
||||
### directories.doc
|
||||
|
||||
Put markdown files in here. Eventually, these will be displayed nicely,
|
||||
maybe, someday.
|
||||
|
||||
### directories.example
|
||||
|
||||
Put example scripts in here. Someday, it might be exposed in some clever way.
|
||||
|
||||
### directories.test
|
||||
|
||||
Put your tests in here. It is currently not exposed, but it might be in the
|
||||
future.
|
||||
|
||||
## repository
|
||||
|
||||
Specify the place where your code lives. This is helpful for people who
|
||||
want to contribute. If the git repo is on GitHub, then the `npm docs`
|
||||
command will be able to find you.
|
||||
|
||||
Do it like this:
|
||||
|
||||
"repository": {
|
||||
"type" : "git",
|
||||
"url" : "https://github.com/npm/cli.git"
|
||||
}
|
||||
|
||||
"repository": {
|
||||
"type" : "svn",
|
||||
"url" : "https://v8.googlecode.com/svn/trunk/"
|
||||
}
|
||||
|
||||
The URL should be a publicly available (perhaps read-only) url that can be handed
|
||||
directly to a VCS program without any modification. It should not be a url to an
|
||||
html project page that you put in your browser. It's for computers.
|
||||
|
||||
For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same
|
||||
shortcut syntax you use for `npm install`:
|
||||
|
||||
"repository": "npm/npm"
|
||||
|
||||
"repository": "github:user/repo"
|
||||
|
||||
"repository": "gist:11081aaa281"
|
||||
|
||||
"repository": "bitbucket:user/repo"
|
||||
|
||||
"repository": "gitlab:user/repo"
|
||||
|
||||
## scripts
|
||||
|
||||
The "scripts" property is a dictionary containing script commands that are run
|
||||
at various times in the lifecycle of your package. The key is the lifecycle
|
||||
event, and the value is the command to run at that point.
|
||||
|
||||
See `npm-scripts(7)` to find out more about writing package scripts.
|
||||
|
||||
## config
|
||||
|
||||
A "config" object can be used to set configuration parameters used in package
|
||||
scripts that persist across upgrades. For instance, if a package had the
|
||||
following:
|
||||
|
||||
{ "name" : "foo"
|
||||
, "config" : { "port" : "8080" } }
|
||||
|
||||
and then had a "start" command that then referenced the
|
||||
`npm_package_config_port` environment variable, then the user could
|
||||
override that by doing `npm config set foo:port 8001`.
|
||||
|
||||
See `npm-config(7)` and `npm-scripts(7)` for more on package
|
||||
configs.
|
||||
|
||||
## dependencies
|
||||
|
||||
Dependencies are specified in a simple object that maps a package name to a
|
||||
version range. The version range is a string which has one or more
|
||||
space-separated descriptors. Dependencies can also be identified with a
|
||||
tarball or git URL.
|
||||
|
||||
**Please do not put test harnesses or transpilers in your
|
||||
`dependencies` object.** See `devDependencies`, below.
|
||||
|
||||
See semver(7) for more details about specifying version ranges.
|
||||
|
||||
* `version` Must match `version` exactly
|
||||
* `>version` Must be greater than `version`
|
||||
* `>=version` etc
|
||||
* `<version`
|
||||
* `<=version`
|
||||
* `~version` "Approximately equivalent to version" See semver(7)
|
||||
* `^version` "Compatible with version" See semver(7)
|
||||
* `1.2.x` 1.2.0, 1.2.1, etc., but not 1.3.0
|
||||
* `http://...` See 'URLs as Dependencies' below
|
||||
* `*` Matches any version
|
||||
* `""` (just an empty string) Same as `*`
|
||||
* `version1 - version2` Same as `>=version1 <=version2`.
|
||||
* `range1 || range2` Passes if either range1 or range2 are satisfied.
|
||||
* `git...` See 'Git URLs as Dependencies' below
|
||||
* `user/repo` See 'GitHub URLs' below
|
||||
* `tag` A specific version tagged and published as `tag` See `npm-dist-tag(1)`
|
||||
* `path/path/path` See [Local Paths](#local-paths) below
|
||||
|
||||
For example, these are all valid:
|
||||
|
||||
{ "dependencies" :
|
||||
{ "foo" : "1.0.0 - 2.9999.9999"
|
||||
, "bar" : ">=1.0.2 <2.1.2"
|
||||
, "baz" : ">1.0.2 <=2.3.4"
|
||||
, "boo" : "2.0.1"
|
||||
, "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
|
||||
, "asd" : "http://asdf.com/asdf.tar.gz"
|
||||
, "til" : "~1.2"
|
||||
, "elf" : "~1.2.3"
|
||||
, "two" : "2.x"
|
||||
, "thr" : "3.3.x"
|
||||
, "lat" : "latest"
|
||||
, "dyl" : "file:../dyl"
|
||||
}
|
||||
}
|
||||
|
||||
### URLs as Dependencies
|
||||
|
||||
You may specify a tarball URL in place of a version range.
|
||||
|
||||
This tarball will be downloaded and installed locally to your package at
|
||||
install time.
|
||||
|
||||
### Git URLs as Dependencies
|
||||
|
||||
Git urls are of the form:
|
||||
|
||||
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
|
||||
|
||||
`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
|
||||
`git+file`.
|
||||
|
||||
If `#<commit-ish>` is provided, it will be used to clone exactly that
|
||||
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
|
||||
be any valid semver range or exact version, and npm will look for any tags
|
||||
or refs matching that range in the remote repository, much as it would for a
|
||||
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
|
||||
specified, then `master` is used.
|
||||
|
||||
Examples:
|
||||
|
||||
git+ssh://git@github.com:npm/cli.git#v1.0.27
|
||||
git+ssh://git@github.com:npm/cli#semver:^5.0
|
||||
git+https://isaacs@github.com/npm/cli.git
|
||||
git://github.com/npm/cli.git#v1.0.27
|
||||
|
||||
### GitHub URLs
|
||||
|
||||
As of version 1.1.65, you can refer to GitHub urls as just "foo":
|
||||
"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be
|
||||
included. For example:
|
||||
|
||||
{
|
||||
"name": "foo",
|
||||
"version": "0.0.0",
|
||||
"dependencies": {
|
||||
"express": "expressjs/express",
|
||||
"mocha": "mochajs/mocha#4727d357ea",
|
||||
"module": "user/repo#feature\/branch"
|
||||
}
|
||||
}
|
||||
|
||||
### Local Paths
|
||||
|
||||
As of version 2.0.0 you can provide a path to a local directory that contains a
|
||||
package. Local paths can be saved using `npm install -S` or
|
||||
`npm install --save`, using any of these forms:
|
||||
|
||||
../foo/bar
|
||||
~/foo/bar
|
||||
./foo/bar
|
||||
/foo/bar
|
||||
|
||||
in which case they will be normalized to a relative path and added to your
|
||||
`package.json`. For example:
|
||||
|
||||
{
|
||||
"name": "baz",
|
||||
"dependencies": {
|
||||
"bar": "file:../foo/bar"
|
||||
}
|
||||
}
|
||||
|
||||
This feature is helpful for local offline development and creating
|
||||
tests that require npm installing where you don't want to hit an
|
||||
external server, but should not be used when publishing packages
|
||||
to the public registry.
|
||||
|
||||
## devDependencies
|
||||
|
||||
If someone is planning on downloading and using your module in their
|
||||
program, then they probably don't want or need to download and build
|
||||
the external test or documentation framework that you use.
|
||||
|
||||
In this case, it's best to map these additional items in a `devDependencies`
|
||||
object.
|
||||
|
||||
These things will be installed when doing `npm link` or `npm install`
|
||||
from the root of a package, and can be managed like any other npm
|
||||
configuration param. See `npm-config(7)` for more on the topic.
|
||||
|
||||
For build steps that are not platform-specific, such as compiling
|
||||
CoffeeScript or other languages to JavaScript, use the `prepare`
|
||||
script to do this, and make the required package a devDependency.
|
||||
|
||||
For example:
|
||||
|
||||
{ "name": "ethopia-waza",
|
||||
"description": "a delightfully fruity coffee varietal",
|
||||
"version": "1.2.3",
|
||||
"devDependencies": {
|
||||
"coffee-script": "~1.6.3"
|
||||
},
|
||||
"scripts": {
|
||||
"prepare": "coffee -o lib/ -c src/waza.coffee"
|
||||
},
|
||||
"main": "lib/waza.js"
|
||||
}
|
||||
|
||||
The `prepare` script will be run before publishing, so that users
|
||||
can consume the functionality without requiring them to compile it
|
||||
themselves. In dev mode (ie, locally running `npm install`), it'll
|
||||
run this script as well, so that you can test it easily.
|
||||
|
||||
## peerDependencies
|
||||
|
||||
In some cases, you want to express the compatibility of your package with a
|
||||
host tool or library, while not necessarily doing a `require` of this host.
|
||||
This is usually referred to as a *plugin*. Notably, your module may be exposing
|
||||
a specific interface, expected and specified by the host documentation.
|
||||
|
||||
For example:
|
||||
|
||||
{
|
||||
"name": "tea-latte",
|
||||
"version": "1.3.5",
|
||||
"peerDependencies": {
|
||||
"tea": "2.x"
|
||||
}
|
||||
}
|
||||
|
||||
This ensures your package `tea-latte` can be installed *along* with the second
|
||||
major version of the host package `tea` only. `npm install tea-latte` could
|
||||
possibly yield the following dependency graph:
|
||||
|
||||
├── tea-latte@1.3.5
|
||||
└── tea@2.2.0
|
||||
|
||||
**NOTE: npm versions 1 and 2 will automatically install `peerDependencies` if
|
||||
they are not explicitly depended upon higher in the dependency tree. In the
|
||||
next major version of npm (npm@3), this will no longer be the case. You will
|
||||
receive a warning that the peerDependency is not installed instead.** The
|
||||
behavior in npms 1 & 2 was frequently confusing and could easily put you into
|
||||
dependency hell, a situation that npm is designed to avoid as much as possible.
|
||||
|
||||
Trying to install another plugin with a conflicting requirement will cause an
|
||||
error. For this reason, make sure your plugin requirement is as broad as
|
||||
possible, and not to lock it down to specific patch versions.
|
||||
|
||||
Assuming the host complies with [semver](https://semver.org/), only changes in
|
||||
the host package's major version will break your plugin. Thus, if you've worked
|
||||
with every 1.x version of the host package, use `"^1.0"` or `"1.x"` to express
|
||||
this. If you depend on features introduced in 1.5.2, use `">= 1.5.2 < 2"`.
|
||||
|
||||
## bundledDependencies
|
||||
|
||||
This defines an array of package names that will be bundled when publishing
|
||||
the package.
|
||||
|
||||
In cases where you need to preserve npm packages locally or have them
|
||||
available through a single file download, you can bundle the packages in a
|
||||
tarball file by specifying the package names in the `bundledDependencies`
|
||||
array and executing `npm pack`.
|
||||
|
||||
For example:
|
||||
|
||||
If we define a package.json like this:
|
||||
|
||||
```
|
||||
{
|
||||
"name": "awesome-web-framework",
|
||||
"version": "1.0.0",
|
||||
"bundledDependencies": [
|
||||
"renderized", "super-streams"
|
||||
]
|
||||
}
|
||||
```
|
||||
we can obtain `awesome-web-framework-1.0.0.tgz` file by running `npm pack`.
|
||||
This file contains the dependencies `renderized` and `super-streams` which
|
||||
can be installed in a new project by executing `npm install
|
||||
awesome-web-framework-1.0.0.tgz`.
|
||||
|
||||
If this is spelled `"bundleDependencies"`, then that is also honored.
|
||||
|
||||
## optionalDependencies
|
||||
|
||||
If a dependency can be used, but you would like npm to proceed if it cannot be
|
||||
found or fails to install, then you may put it in the `optionalDependencies`
|
||||
object. This is a map of package name to version or url, just like the
|
||||
`dependencies` object. The difference is that build failures do not cause
|
||||
installation to fail.
|
||||
|
||||
It is still your program's responsibility to handle the lack of the
|
||||
dependency. For example, something like this:
|
||||
|
||||
try {
|
||||
var foo = require('foo')
|
||||
var fooVersion = require('foo/package.json').version
|
||||
} catch (er) {
|
||||
foo = null
|
||||
}
|
||||
if ( notGoodFooVersion(fooVersion) ) {
|
||||
foo = null
|
||||
}
|
||||
|
||||
// .. then later in your program ..
|
||||
|
||||
if (foo) {
|
||||
foo.doFooThings()
|
||||
}
|
||||
|
||||
Entries in `optionalDependencies` will override entries of the same name in
|
||||
`dependencies`, so it's usually best to only put in one place.
|
||||
|
||||
## engines
|
||||
|
||||
You can specify the version of node that your stuff works on:
|
||||
|
||||
{ "engines" : { "node" : ">=0.10.3 <0.12" } }
|
||||
|
||||
And, like with dependencies, if you don't specify the version (or if you
|
||||
specify "\*" as the version), then any version of node will do.
|
||||
|
||||
If you specify an "engines" field, then npm will require that "node" be
|
||||
somewhere on that list. If "engines" is omitted, then npm will just assume
|
||||
that it works on node.
|
||||
|
||||
You can also use the "engines" field to specify which versions of npm
|
||||
are capable of properly installing your program. For example:
|
||||
|
||||
{ "engines" : { "npm" : "~1.0.20" } }
|
||||
|
||||
Unless the user has set the `engine-strict` config flag, this
|
||||
field is advisory only and will only produce warnings when your package is installed as a dependency.
|
||||
|
||||
## engineStrict
|
||||
|
||||
**This feature was removed in npm 3.0.0**
|
||||
|
||||
Prior to npm 3.0.0, this feature was used to treat this package as if the
|
||||
user had set `engine-strict`. It is no longer used.
|
||||
|
||||
## os
|
||||
|
||||
You can specify which operating systems your
|
||||
module will run on:
|
||||
|
||||
"os" : [ "darwin", "linux" ]
|
||||
|
||||
You can also blacklist instead of whitelist operating systems,
|
||||
just prepend the blacklisted os with a '!':
|
||||
|
||||
"os" : [ "!win32" ]
|
||||
|
||||
The host operating system is determined by `process.platform`
|
||||
|
||||
It is allowed to both blacklist, and whitelist, although there isn't any
|
||||
good reason to do this.
|
||||
|
||||
## cpu
|
||||
|
||||
If your code only runs on certain cpu architectures,
|
||||
you can specify which ones.
|
||||
|
||||
"cpu" : [ "x64", "ia32" ]
|
||||
|
||||
Like the `os` option, you can also blacklist architectures:
|
||||
|
||||
"cpu" : [ "!arm", "!mips" ]
|
||||
|
||||
The host architecture is determined by `process.arch`
|
||||
|
||||
## preferGlobal
|
||||
|
||||
**DEPRECATED**
|
||||
|
||||
This option used to trigger an npm warning, but it will no longer warn. It is
|
||||
purely there for informational purposes. It is now recommended that you install
|
||||
any binaries as local devDependencies wherever possible.
|
||||
|
||||
## private
|
||||
|
||||
If you set `"private": true` in your package.json, then npm will refuse
|
||||
to publish it.
|
||||
|
||||
This is a way to prevent accidental publication of private repositories. If
|
||||
you would like to ensure that a given package is only ever published to a
|
||||
specific registry (for example, an internal registry), then use the
|
||||
`publishConfig` dictionary described below to override the `registry` config
|
||||
param at publish-time.
|
||||
|
||||
## publishConfig
|
||||
|
||||
This is a set of config values that will be used at publish-time. It's
|
||||
especially handy if you want to set the tag, registry or access, so that
|
||||
you can ensure that a given package is not tagged with "latest", published
|
||||
to the global public registry or that a scoped module is private by default.
|
||||
|
||||
Any config values can be overridden, but only "tag", "registry" and "access"
|
||||
probably matter for the purposes of publishing.
|
||||
|
||||
See `npm-config(7)` to see the list of config options that can be
|
||||
overridden.
|
||||
|
||||
## DEFAULT VALUES
|
||||
|
||||
npm will default some values based on package contents.
|
||||
|
||||
* `"scripts": {"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`.
|
||||
|
||||
* `"scripts":{"install": "node-gyp rebuild"}`
|
||||
|
||||
If there is a `binding.gyp` file in the root of your package and you have not defined an `install` or `preinstall` script, npm will
|
||||
default the `install` command to compile using node-gyp.
|
||||
|
||||
* `"contributors": [...]`
|
||||
|
||||
If there is an `AUTHORS` file in the root of your package, npm will
|
||||
treat each line as a `Name <email> (url)` format, where email and url
|
||||
are optional. Lines which start with a `#` or are blank, will be
|
||||
ignored.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* semver(7)
|
||||
* npm-init(1)
|
||||
* npm-version(1)
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npm-help(1)
|
||||
* npm-install(1)
|
||||
* npm-publish(1)
|
||||
* npm-uninstall(1)
|
||||
192
website/node_modules/npm/doc/misc/npm-coding-style.md
generated
vendored
Normal file
192
website/node_modules/npm/doc/misc/npm-coding-style.md
generated
vendored
Normal file
@@ -0,0 +1,192 @@
|
||||
npm-coding-style(7) -- npm's "funny" coding style
|
||||
=================================================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
npm's coding style is a bit unconventional. It is not different for
|
||||
difference's sake, but rather a carefully crafted style that is
|
||||
designed to reduce visual clutter and make bugs more apparent.
|
||||
|
||||
If you want to contribute to npm (which is very encouraged), you should
|
||||
make your code conform to npm's style.
|
||||
|
||||
Note: this concerns npm's code not the specific packages that you can download from the npm registry.
|
||||
|
||||
## Line Length
|
||||
|
||||
Keep lines shorter than 80 characters. It's better for lines to be
|
||||
too short than to be too long. Break up long lists, objects, and other
|
||||
statements onto multiple lines.
|
||||
|
||||
## Indentation
|
||||
|
||||
Two-spaces. Tabs are better, but they look like hell in web browsers
|
||||
(and on GitHub), and node uses 2 spaces, so that's that.
|
||||
|
||||
Configure your editor appropriately.
|
||||
|
||||
## Curly braces
|
||||
|
||||
Curly braces belong on the same line as the thing that necessitates them.
|
||||
|
||||
Bad:
|
||||
|
||||
function ()
|
||||
{
|
||||
|
||||
Good:
|
||||
|
||||
function () {
|
||||
|
||||
If a block needs to wrap to the next line, use a curly brace. Don't
|
||||
use it if it doesn't.
|
||||
|
||||
Bad:
|
||||
|
||||
if (foo) { bar() }
|
||||
while (foo)
|
||||
bar()
|
||||
|
||||
Good:
|
||||
|
||||
if (foo) bar()
|
||||
while (foo) {
|
||||
bar()
|
||||
}
|
||||
|
||||
## Semicolons
|
||||
|
||||
Don't use them except in four situations:
|
||||
|
||||
* `for (;;)` loops. They're actually required.
|
||||
* null loops like: `while (something) ;` (But you'd better have a good
|
||||
reason for doing that.)
|
||||
* `case 'foo': doSomething(); break`
|
||||
* In front of a leading `(` or `[` at the start of the line.
|
||||
This prevents the expression from being interpreted
|
||||
as a function call or property access, respectively.
|
||||
|
||||
Some examples of good semicolon usage:
|
||||
|
||||
;(x || y).doSomething()
|
||||
;[a, b, c].forEach(doSomething)
|
||||
for (var i = 0; i < 10; i ++) {
|
||||
switch (state) {
|
||||
case 'begin': start(); continue
|
||||
case 'end': finish(); break
|
||||
default: throw new Error('unknown state')
|
||||
}
|
||||
end()
|
||||
}
|
||||
|
||||
Note that starting lines with `-` and `+` also should be prefixed
|
||||
with a semicolon, but this is much less common.
|
||||
|
||||
## Comma First
|
||||
|
||||
If there is a list of things separated by commas, and it wraps
|
||||
across multiple lines, put the comma at the start of the next
|
||||
line, directly below the token that starts the list. Put the
|
||||
final token in the list on a line by itself. For example:
|
||||
|
||||
var magicWords = [ 'abracadabra'
|
||||
, 'gesundheit'
|
||||
, 'ventrilo'
|
||||
]
|
||||
, spells = { 'fireball' : function () { setOnFire() }
|
||||
, 'water' : function () { putOut() }
|
||||
}
|
||||
, a = 1
|
||||
, b = 'abc'
|
||||
, etc
|
||||
, somethingElse
|
||||
|
||||
## Quotes
|
||||
Use single quotes for strings except to avoid escaping.
|
||||
|
||||
Bad:
|
||||
|
||||
var notOk = "Just double quotes"
|
||||
|
||||
Good:
|
||||
|
||||
var ok = 'String contains "double" quotes'
|
||||
var alsoOk = "String contains 'single' quotes or apostrophe"
|
||||
|
||||
## Whitespace
|
||||
|
||||
Put a single space in front of `(` for anything other than a function call.
|
||||
Also use a single space wherever it makes things more readable.
|
||||
|
||||
Don't leave trailing whitespace at the end of lines. Don't indent empty
|
||||
lines. Don't use more spaces than are helpful.
|
||||
|
||||
## Functions
|
||||
|
||||
Use named functions. They make stack traces a lot easier to read.
|
||||
|
||||
## Callbacks, Sync/async Style
|
||||
|
||||
Use the asynchronous/non-blocking versions of things as much as possible.
|
||||
It might make more sense for npm to use the synchronous fs APIs, but this
|
||||
way, the fs and http and child process stuff all uses the same callback-passing
|
||||
methodology.
|
||||
|
||||
The callback should always be the last argument in the list. Its first
|
||||
argument is the Error or null.
|
||||
|
||||
Be very careful never to ever ever throw anything. It's worse than useless.
|
||||
Just send the error message back as the first argument to the callback.
|
||||
|
||||
## Errors
|
||||
|
||||
Always create a new Error object with your message. Don't just return a
|
||||
string message to the callback. Stack traces are handy.
|
||||
|
||||
## Logging
|
||||
|
||||
Logging is done using the [npmlog](https://github.com/npm/npmlog)
|
||||
utility.
|
||||
|
||||
Please clean up logs when they are no longer helpful. In particular,
|
||||
logging the same object over and over again is not helpful. Logs should
|
||||
report what's happening so that it's easier to track down where a fault
|
||||
occurs.
|
||||
|
||||
Use appropriate log levels. See `npm-config(7)` and search for
|
||||
"loglevel".
|
||||
|
||||
## Case, naming, etc.
|
||||
|
||||
Use `lowerCamelCase` for multiword identifiers when they refer to objects,
|
||||
functions, methods, properties, or anything not specified in this section.
|
||||
|
||||
Use `UpperCamelCase` for class names (things that you'd pass to "new").
|
||||
|
||||
Use `all-lower-hyphen-css-case` for multiword filenames and config keys.
|
||||
|
||||
Use named functions. They make stack traces easier to follow.
|
||||
|
||||
Use `CAPS_SNAKE_CASE` for constants, things that should never change
|
||||
and are rarely used.
|
||||
|
||||
Use a single uppercase letter for function names where the function
|
||||
would normally be anonymous, but needs to call itself recursively. It
|
||||
makes it clear that it's a "throwaway" function.
|
||||
|
||||
## null, undefined, false, 0
|
||||
|
||||
Boolean variables and functions should always be either `true` or
|
||||
`false`. Don't set it to 0 unless it's supposed to be a number.
|
||||
|
||||
When something is intentionally missing or removed, set it to `null`.
|
||||
|
||||
Don't set things to `undefined`. Reserve that value to mean "not yet
|
||||
set to anything."
|
||||
|
||||
Boolean objects are forbidden.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-developers(7)
|
||||
* npm(1)
|
||||
1243
website/node_modules/npm/doc/misc/npm-config.md
generated
vendored
Normal file
1243
website/node_modules/npm/doc/misc/npm-config.md
generated
vendored
Normal file
File diff suppressed because it is too large
Load Diff
233
website/node_modules/npm/doc/misc/npm-developers.md
generated
vendored
Normal file
233
website/node_modules/npm/doc/misc/npm-developers.md
generated
vendored
Normal file
@@ -0,0 +1,233 @@
|
||||
npm-developers(7) -- Developer Guide
|
||||
====================================
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
So, you've decided to use npm to develop (and maybe publish/deploy)
|
||||
your project.
|
||||
|
||||
Fantastic!
|
||||
|
||||
There are a few things that you need to do above the simple steps
|
||||
that your users will do to install your program.
|
||||
|
||||
## About These Documents
|
||||
|
||||
These are man pages. If you install npm, you should be able to
|
||||
then do `man npm-thing` to get the documentation on a particular
|
||||
topic, or `npm help thing` to see the same information.
|
||||
|
||||
## 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`.
|
||||
|
||||
## The package.json File
|
||||
|
||||
You need to have a `package.json` file in the root of your project to do
|
||||
much of anything with npm. That is basically the whole interface.
|
||||
|
||||
See `package.json(5)` for details about what goes in that file. At the very
|
||||
least, you need:
|
||||
|
||||
* name:
|
||||
This should be a string that identifies your project. Please do not
|
||||
use the name to specify that it runs on node, or is in JavaScript.
|
||||
You can use the "engines" field to explicitly state the versions of
|
||||
node (or whatever else) that your program requires, and it's pretty
|
||||
well assumed that it's JavaScript.
|
||||
|
||||
It does not necessarily need to match your github repository name.
|
||||
|
||||
So, `node-foo` and `bar-js` are bad names. `foo` or `bar` are better.
|
||||
|
||||
* version:
|
||||
A semver-compatible version.
|
||||
|
||||
* engines:
|
||||
Specify the versions of node (or whatever else) that your program
|
||||
runs on. The node API changes a lot, and there may be bugs or new
|
||||
functionality that you depend on. Be explicit.
|
||||
|
||||
* author:
|
||||
Take some credit.
|
||||
|
||||
* scripts:
|
||||
If you have a special compilation or installation script, then you
|
||||
should put it in the `scripts` object. You should definitely have at
|
||||
least a basic smoke-test command as the "scripts.test" field.
|
||||
See npm-scripts(7).
|
||||
|
||||
* main:
|
||||
If you have a single module that serves as the entry point to your
|
||||
program (like what the "foo" package gives you at require("foo")),
|
||||
then you need to specify that in the "main" field.
|
||||
|
||||
* directories:
|
||||
This is an object mapping names to folders. The best ones to include are
|
||||
"lib" and "doc", but if you use "man" to specify a folder full of man pages,
|
||||
they'll get installed just like these ones.
|
||||
|
||||
You can use `npm init` in the root of your package in order to get you
|
||||
started with a pretty basic package.json file. See `npm-init(1)` for
|
||||
more info.
|
||||
|
||||
## Keeping files *out* of your package
|
||||
|
||||
Use a `.npmignore` file to keep stuff out of your package. If there's
|
||||
no `.npmignore` file, but there *is* a `.gitignore` file, then npm will
|
||||
ignore the stuff matched by the `.gitignore` file. If you *want* to
|
||||
include something that is excluded by your `.gitignore` file, you can
|
||||
create an empty `.npmignore` file to override it. Like `git`, `npm` looks
|
||||
for `.npmignore` and `.gitignore` files in all subdirectories of your
|
||||
package, not only the root directory.
|
||||
|
||||
`.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#Ignoring-Files)
|
||||
as `.gitignore` files:
|
||||
|
||||
* Blank lines or lines starting with `#` are ignored.
|
||||
* Standard glob patterns work.
|
||||
* You can end patterns with a forward slash `/` to specify a directory.
|
||||
* You can negate a pattern by starting it with an exclamation point `!`.
|
||||
|
||||
By default, the following paths and files are ignored, so there's no
|
||||
need to add them to `.npmignore` explicitly:
|
||||
|
||||
* `.*.swp`
|
||||
* `._*`
|
||||
* `.DS_Store`
|
||||
* `.git`
|
||||
* `.hg`
|
||||
* `.npmrc`
|
||||
* `.lock-wscript`
|
||||
* `.svn`
|
||||
* `.wafpickle-*`
|
||||
* `config.gypi`
|
||||
* `CVS`
|
||||
* `npm-debug.log`
|
||||
|
||||
Additionally, everything in `node_modules` is ignored, except for
|
||||
bundled dependencies. npm automatically handles this for you, so don't
|
||||
bother adding `node_modules` to `.npmignore`.
|
||||
|
||||
The following paths and files are never ignored, so adding them to
|
||||
`.npmignore` is pointless:
|
||||
|
||||
* `package.json`
|
||||
* `README` (and its variants)
|
||||
* `CHANGELOG` (and its variants)
|
||||
* `LICENSE` / `LICENCE`
|
||||
|
||||
If, given the structure of your project, you find `.npmignore` to be a
|
||||
maintenance headache, you might instead try populating the `files`
|
||||
property of `package.json`, which is an array of file or directory names
|
||||
that should be included in your package. Sometimes a whitelist is easier
|
||||
to manage than a blacklist.
|
||||
|
||||
### Testing whether your `.npmignore` or `files` config works
|
||||
|
||||
If you want to double check that your package will include only the files
|
||||
you intend it to when published, you can run the `npm pack` command locally
|
||||
which will generate a tarball in the working directory, the same way it
|
||||
does for publishing.
|
||||
|
||||
## Link Packages
|
||||
|
||||
`npm link` is designed to install a development package and see the
|
||||
changes in real time without having to keep re-installing it. (You do
|
||||
need to either re-link or `npm rebuild -g` to update compiled packages,
|
||||
of course.)
|
||||
|
||||
More info at `npm-link(1)`.
|
||||
|
||||
## Before Publishing: Make Sure Your Package Installs and Works
|
||||
|
||||
**This is important.**
|
||||
|
||||
If you can not install it locally, you'll have
|
||||
problems trying to publish it. Or, worse yet, you'll be able to
|
||||
publish it, but you'll be publishing a broken or pointless package.
|
||||
So don't do that.
|
||||
|
||||
In the root of your package, do this:
|
||||
|
||||
npm install . -g
|
||||
|
||||
That'll show you that it's working. If you'd rather just create a symlink
|
||||
package that points to your working directory, then do this:
|
||||
|
||||
npm link
|
||||
|
||||
Use `npm ls -g` to see if it's there.
|
||||
|
||||
To test a local install, go into some other folder, and then do:
|
||||
|
||||
cd ../some-other-folder
|
||||
npm install ../my-package
|
||||
|
||||
to install it locally into the node_modules folder in that other place.
|
||||
|
||||
Then go into the node-repl, and try using require("my-thing") to
|
||||
bring in your module's main module.
|
||||
|
||||
## Create a User Account
|
||||
|
||||
Create a user with the adduser command. It works like this:
|
||||
|
||||
npm adduser
|
||||
|
||||
and then follow the prompts.
|
||||
|
||||
This is documented better in npm-adduser(1).
|
||||
|
||||
## Publish your package
|
||||
|
||||
This part's easy. In the root of your folder, do this:
|
||||
|
||||
npm publish
|
||||
|
||||
You can give publish a url to a tarball, or a filename of a tarball,
|
||||
or a path to a folder.
|
||||
|
||||
Note that pretty much **everything in that folder will be exposed**
|
||||
by default. So, if you have secret stuff in there, use a
|
||||
`.npmignore` file to list out the globs to ignore, or publish
|
||||
from a fresh checkout.
|
||||
|
||||
## Brag about it
|
||||
|
||||
Send emails, write blogs, blab in IRC.
|
||||
|
||||
Tell the world how easy it is to install your program!
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm(1)
|
||||
* npm-init(1)
|
||||
* package.json(5)
|
||||
* npm-scripts(7)
|
||||
* npm-publish(1)
|
||||
* npm-adduser(1)
|
||||
* npm-registry(7)
|
||||
130
website/node_modules/npm/doc/misc/npm-disputes.md
generated
vendored
Normal file
130
website/node_modules/npm/doc/misc/npm-disputes.md
generated
vendored
Normal file
@@ -0,0 +1,130 @@
|
||||
npm-disputes(7) -- Handling Module Name Disputes
|
||||
================================================
|
||||
|
||||
This document describes the steps that you should take to resolve module name
|
||||
disputes with other npm publishers. It also describes special steps you should
|
||||
take about names you think infringe your trademarks.
|
||||
|
||||
This document is a clarification of the acceptable behavior outlined in the
|
||||
[npm Code of Conduct](https://www.npmjs.com/policies/conduct), and nothing in
|
||||
this document should be interpreted to contradict any aspect of the npm Code of
|
||||
Conduct.
|
||||
|
||||
## TL;DR
|
||||
|
||||
1. Get the author email with `npm owner ls <pkgname>`
|
||||
2. Email the author, CC <support@npmjs.com>
|
||||
3. After a few weeks, if there's no resolution, we'll sort it out.
|
||||
|
||||
Don't squat on package names. Publish code or move out of the way.
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
There sometimes arise cases where a user publishes a module, and then later,
|
||||
some other user wants to use that name. Here are some common ways that happens
|
||||
(each of these is based on actual events.)
|
||||
|
||||
1. Alice writes a JavaScript module `foo`, which is not node-specific. Alice
|
||||
doesn't use node at all. Yusuf wants to use `foo` in node, so he wraps it in
|
||||
an npm module. Some time later, Alice starts using node, and wants to take
|
||||
over management of her program.
|
||||
2. Yusuf writes an npm module `foo`, and publishes it. Perhaps much later, Alice
|
||||
finds a bug in `foo`, and fixes it. She sends a pull request to Yusuf, but
|
||||
Yusuf doesn't have the time to deal with it, because he has a new job and a
|
||||
new baby and is focused on his new Erlang project, and kind of not involved
|
||||
with node any more. Alice would like to publish a new `foo`, but can't,
|
||||
because the name is taken.
|
||||
3. Yusuf writes a 10-line flow-control library, and calls it `foo`, and
|
||||
publishes it to the npm registry. Being a simple little thing, it never
|
||||
really has to be updated. Alice works for Foo Inc, the makers of the
|
||||
critically acclaimed and widely-marketed `foo` JavaScript toolkit framework.
|
||||
They publish it to npm as `foojs`, but people are routinely confused when
|
||||
`npm install foo` is some different thing.
|
||||
4. Yusuf writes a parser for the widely-known `foo` file format, because he
|
||||
needs it for work. Then, he gets a new job, and never updates the prototype.
|
||||
Later on, Alice writes a much more complete `foo` parser, but can't publish,
|
||||
because Yusuf's `foo` is in the way.
|
||||
|
||||
1. `npm owner ls foo`. This will tell Alice the email address of the owner
|
||||
(Yusuf).
|
||||
2. Alice emails Yusuf, explaining the situation **as respectfully as possible**,
|
||||
and what she would like to do with the module name. She adds the npm support
|
||||
staff <support@npmjs.com> to the CC list of the email. Mention in the email
|
||||
that Yusuf can run npm owner `add alice foo` to add Alice as an owner of the
|
||||
foo package.
|
||||
3. After a reasonable amount of time, if Yusuf has not responded, or if Yusuf
|
||||
and Alice can't come to any sort of resolution, email support
|
||||
<support@npmjs.com> and we'll sort it out. ("Reasonable" is usually at least
|
||||
4 weeks.)
|
||||
|
||||
## REASONING
|
||||
|
||||
In almost every case so far, the parties involved have been able to reach an
|
||||
amicable resolution without any major intervention. Most people really do want
|
||||
to be reasonable, and are probably not even aware that they're in your way.
|
||||
|
||||
Module ecosystems are most vibrant and powerful when they are as self-directed
|
||||
as possible. If an admin one day deletes something you had worked on, then that
|
||||
is going to make most people quite upset, regardless of the justification. When
|
||||
humans solve their problems by talking to other humans with respect, everyone
|
||||
has the chance to end up feeling good about the interaction.
|
||||
|
||||
## EXCEPTIONS
|
||||
|
||||
Some things are not allowed, and will be removed without discussion if they are
|
||||
brought to the attention of the npm registry admins, including but not limited
|
||||
to:
|
||||
|
||||
1. Malware (that is, a package designed to exploit or harm the machine on which
|
||||
it is installed).
|
||||
2. Violations of copyright or licenses (for example, cloning an MIT-licensed
|
||||
program, and then removing or changing the copyright and license statement).
|
||||
3. Illegal content.
|
||||
4. "Squatting" on a package name that you plan to use, but aren't actually
|
||||
using. Sorry, I don't care how great the name is, or how perfect a fit it is
|
||||
for the thing that someday might happen. If someone wants to use it today,
|
||||
and you're just taking up space with an empty tarball, you're going to be
|
||||
evicted.
|
||||
5. Putting empty packages in the registry. Packages must have SOME
|
||||
functionality. It can be silly, but it can't be nothing. (See also:
|
||||
squatting.)
|
||||
6. Doing weird things with the registry, like using it as your own personal
|
||||
application database or otherwise putting non-packagey things into it.
|
||||
7. Other things forbidden by the npm
|
||||
[Code of Conduct](https://www.npmjs.com/policies/conduct) such as hateful
|
||||
language, pornographic content, or harassment.
|
||||
|
||||
If you see bad behavior like this, please report it to <abuse@npmjs.com> right
|
||||
away. **You are never expected to resolve abusive behavior on your own. We are
|
||||
here to help.**
|
||||
|
||||
## TRADEMARKS
|
||||
|
||||
If you think another npm publisher is infringing your trademark, such as by
|
||||
using a confusingly similar package name, email <abuse@npmjs.com> with a link to
|
||||
the package or user account on [https://www.npmjs.com/](https://www.npmjs.com/).
|
||||
Attach a copy of your trademark registration certificate.
|
||||
|
||||
If we see that the package's publisher is intentionally misleading others by
|
||||
misusing your registered mark without permission, we will transfer the package
|
||||
name to you. Otherwise, we will contact the package publisher and ask them to
|
||||
clear up any confusion with changes to their package's `README` file or
|
||||
metadata.
|
||||
|
||||
## CHANGES
|
||||
|
||||
This is a living document and may be updated from time to time. Please refer to
|
||||
the [git history for this document](https://github.com/npm/cli/commits/latest/doc/misc/npm-disputes.md)
|
||||
to view the changes.
|
||||
|
||||
## LICENSE
|
||||
|
||||
Copyright (C) npm, Inc., All rights reserved
|
||||
|
||||
This document may be reused under a Creative Commons Attribution-ShareAlike
|
||||
License.
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-registry(7)
|
||||
* npm-owner(1)
|
||||
319
website/node_modules/npm/doc/misc/npm-index.md
generated
vendored
Normal file
319
website/node_modules/npm/doc/misc/npm-index.md
generated
vendored
Normal file
@@ -0,0 +1,319 @@
|
||||
npm-index(7) -- Index of all npm documentation
|
||||
==============================================
|
||||
|
||||
### README(1)
|
||||
|
||||
a JavaScript package manager
|
||||
|
||||
## Command Line Documentation
|
||||
|
||||
Using npm on the command line
|
||||
|
||||
### npm(1)
|
||||
|
||||
javascript package manager
|
||||
|
||||
### npm-access(1)
|
||||
|
||||
Set access level on published packages
|
||||
|
||||
### npm-adduser(1)
|
||||
|
||||
Add a registry user account
|
||||
|
||||
### npm-audit(1)
|
||||
|
||||
Run a security audit
|
||||
|
||||
### npm-bin(1)
|
||||
|
||||
Display npm bin folder
|
||||
|
||||
### npm-bugs(1)
|
||||
|
||||
Bugs for a package in a web browser maybe
|
||||
|
||||
### npm-build(1)
|
||||
|
||||
Build a package
|
||||
|
||||
### npm-bundle(1)
|
||||
|
||||
REMOVED
|
||||
|
||||
### npm-cache(1)
|
||||
|
||||
Manipulates packages cache
|
||||
|
||||
### npm-ci(1)
|
||||
|
||||
Install a project with a clean slate
|
||||
|
||||
### npm-completion(1)
|
||||
|
||||
Tab Completion for npm
|
||||
|
||||
### npm-config(1)
|
||||
|
||||
Manage the npm configuration files
|
||||
|
||||
### npm-dedupe(1)
|
||||
|
||||
Reduce duplication
|
||||
|
||||
### npm-deprecate(1)
|
||||
|
||||
Deprecate a version of a package
|
||||
|
||||
### npm-dist-tag(1)
|
||||
|
||||
Modify package distribution tags
|
||||
|
||||
### npm-docs(1)
|
||||
|
||||
Docs for a package in a web browser maybe
|
||||
|
||||
### npm-doctor(1)
|
||||
|
||||
Check your environments
|
||||
|
||||
### npm-edit(1)
|
||||
|
||||
Edit an installed package
|
||||
|
||||
### npm-explore(1)
|
||||
|
||||
Browse an installed package
|
||||
|
||||
### npm-help-search(1)
|
||||
|
||||
Search npm help documentation
|
||||
|
||||
### npm-help(1)
|
||||
|
||||
Get help on npm
|
||||
|
||||
### npm-hook(1)
|
||||
|
||||
Manage registry hooks
|
||||
|
||||
### npm-init(1)
|
||||
|
||||
create a package.json file
|
||||
|
||||
### npm-install-ci-test(1)
|
||||
|
||||
Install a project with a clean slate and run tests
|
||||
|
||||
### npm-install-test(1)
|
||||
|
||||
Install package(s) and run tests
|
||||
|
||||
### npm-install(1)
|
||||
|
||||
Install a package
|
||||
|
||||
### npm-link(1)
|
||||
|
||||
Symlink a package folder
|
||||
|
||||
### npm-logout(1)
|
||||
|
||||
Log out of the registry
|
||||
|
||||
### npm-ls(1)
|
||||
|
||||
List installed packages
|
||||
|
||||
### npm-outdated(1)
|
||||
|
||||
Check for outdated packages
|
||||
|
||||
### npm-owner(1)
|
||||
|
||||
Manage package owners
|
||||
|
||||
### npm-pack(1)
|
||||
|
||||
Create a tarball from a package
|
||||
|
||||
### npm-ping(1)
|
||||
|
||||
Ping npm registry
|
||||
|
||||
### npm-prefix(1)
|
||||
|
||||
Display prefix
|
||||
|
||||
### npm-profile(1)
|
||||
|
||||
Change settings on your registry profile
|
||||
|
||||
### npm-prune(1)
|
||||
|
||||
Remove extraneous packages
|
||||
|
||||
### npm-publish(1)
|
||||
|
||||
Publish a package
|
||||
|
||||
### npm-rebuild(1)
|
||||
|
||||
Rebuild a package
|
||||
|
||||
### npm-repo(1)
|
||||
|
||||
Open package repository page in the browser
|
||||
|
||||
### npm-restart(1)
|
||||
|
||||
Restart a package
|
||||
|
||||
### npm-root(1)
|
||||
|
||||
Display npm root
|
||||
|
||||
### npm-run-script(1)
|
||||
|
||||
Run arbitrary package scripts
|
||||
|
||||
### npm-search(1)
|
||||
|
||||
Search for packages
|
||||
|
||||
### npm-shrinkwrap(1)
|
||||
|
||||
Lock down dependency versions for publication
|
||||
|
||||
### npm-star(1)
|
||||
|
||||
Mark your favorite packages
|
||||
|
||||
### npm-stars(1)
|
||||
|
||||
View packages marked as favorites
|
||||
|
||||
### npm-start(1)
|
||||
|
||||
Start a package
|
||||
|
||||
### npm-stop(1)
|
||||
|
||||
Stop a package
|
||||
|
||||
### npm-team(1)
|
||||
|
||||
Manage organization teams and team memberships
|
||||
|
||||
### npm-test(1)
|
||||
|
||||
Test a package
|
||||
|
||||
### npm-token(1)
|
||||
|
||||
Manage your authentication tokens
|
||||
|
||||
### npm-uninstall(1)
|
||||
|
||||
Remove a package
|
||||
|
||||
### npm-unpublish(1)
|
||||
|
||||
Remove a package from the registry
|
||||
|
||||
### npm-update(1)
|
||||
|
||||
Update a package
|
||||
|
||||
### npm-version(1)
|
||||
|
||||
Bump a package version
|
||||
|
||||
### npm-view(1)
|
||||
|
||||
View registry info
|
||||
|
||||
### npm-whoami(1)
|
||||
|
||||
Display npm username
|
||||
|
||||
## API Documentation
|
||||
|
||||
Using npm in your Node programs
|
||||
|
||||
## Files
|
||||
|
||||
File system structures npm uses
|
||||
|
||||
### npm-folders(5)
|
||||
|
||||
Folder Structures Used by npm
|
||||
|
||||
### npm-package-locks(5)
|
||||
|
||||
An explanation of npm lockfiles
|
||||
|
||||
### npm-shrinkwrap.json(5)
|
||||
|
||||
A publishable lockfile
|
||||
|
||||
### npmrc(5)
|
||||
|
||||
The npm config files
|
||||
|
||||
### package-lock.json(5)
|
||||
|
||||
A manifestation of the manifest
|
||||
|
||||
### package.json(5)
|
||||
|
||||
Specifics of npm's package.json handling
|
||||
|
||||
## Misc
|
||||
|
||||
Various other bits and bobs
|
||||
|
||||
### npm-coding-style(7)
|
||||
|
||||
npm's "funny" coding style
|
||||
|
||||
### npm-config(7)
|
||||
|
||||
More than you probably want to know about npm configuration
|
||||
|
||||
### npm-developers(7)
|
||||
|
||||
Developer Guide
|
||||
|
||||
### npm-disputes(7)
|
||||
|
||||
Handling Module Name Disputes
|
||||
|
||||
### npm-index(7)
|
||||
|
||||
Index of all npm documentation
|
||||
|
||||
### npm-orgs(7)
|
||||
|
||||
Working with Teams & Orgs
|
||||
|
||||
### npm-registry(7)
|
||||
|
||||
The JavaScript Package Registry
|
||||
|
||||
### npm-scope(7)
|
||||
|
||||
Scoped packages
|
||||
|
||||
### npm-scripts(7)
|
||||
|
||||
How npm handles the "scripts" field
|
||||
|
||||
### removing-npm(7)
|
||||
|
||||
Cleaning the Slate
|
||||
|
||||
### semver(7)
|
||||
|
||||
The semantic versioner for npm
|
||||
|
||||
90
website/node_modules/npm/doc/misc/npm-orgs.md
generated
vendored
Normal file
90
website/node_modules/npm/doc/misc/npm-orgs.md
generated
vendored
Normal file
@@ -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)
|
||||
100
website/node_modules/npm/doc/misc/npm-registry.md
generated
vendored
Normal file
100
website/node_modules/npm/doc/misc/npm-registry.md
generated
vendored
Normal file
@@ -0,0 +1,100 @@
|
||||
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.
|
||||
|
||||
npm is configured to use npm, Inc.'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://www.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 may be governed by their
|
||||
terms of use.
|
||||
|
||||
npm's package registry implementation supports several
|
||||
write APIs as well, to allow for publishing packages and managing user
|
||||
account information.
|
||||
|
||||
The npm public registry 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
|
||||
continuous 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 try 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://www.npmjs.com/>
|
||||
|
||||
## SEE ALSO
|
||||
|
||||
* npm-config(1)
|
||||
* npm-config(7)
|
||||
* npmrc(5)
|
||||
* npm-developers(7)
|
||||
* npm-disputes(7)
|
||||
113
website/node_modules/npm/doc/misc/npm-scope.md
generated
vendored
Normal file
113
website/node_modules/npm/doc/misc/npm-scope.md
generated
vendored
Normal file
@@ -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://docs.npmjs.com/private-modules/intro)
|
||||
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)
|
||||
268
website/node_modules/npm/doc/misc/npm-scripts.md
generated
vendored
Normal file
268
website/node_modules/npm/doc/misc/npm-scripts.md
generated
vendored
Normal file
@@ -0,0 +1,268 @@
|
||||
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, on local `npm
|
||||
install` without any arguments, and when installing git dependencies (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". You can access these variables
|
||||
in your code with `process.env.npm_package_name` and
|
||||
`process.env.npm_package_version`, and so on for other fields.
|
||||
|
||||
### 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)
|
||||
54
website/node_modules/npm/doc/misc/removing-npm.md
generated
vendored
Normal file
54
website/node_modules/npm/doc/misc/removing-npm.md
generated
vendored
Normal file
@@ -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)
|
||||
388
website/node_modules/npm/doc/misc/semver.md
generated
vendored
Normal file
388
website/node_modules/npm/doc/misc/semver.md
generated
vendored
Normal file
@@ -0,0 +1,388 @@
|
||||
semver(7) -- The semantic versioner for npm
|
||||
===========================================
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
npm install --save semver
|
||||
````
|
||||
|
||||
## Usage
|
||||
|
||||
As a node module:
|
||||
|
||||
```js
|
||||
const semver = require('semver')
|
||||
|
||||
semver.valid('1.2.3') // '1.2.3'
|
||||
semver.valid('a.b.c') // null
|
||||
semver.clean(' =v1.2.3 ') // '1.2.3'
|
||||
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
|
||||
semver.gt('1.2.3', '9.8.7') // false
|
||||
semver.lt('1.2.3', '9.8.7') // true
|
||||
semver.valid(semver.coerce('v2')) // '2.0.0'
|
||||
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // '42.6.7'
|
||||
```
|
||||
|
||||
As a command-line utility:
|
||||
|
||||
```
|
||||
$ semver -h
|
||||
|
||||
SemVer 5.3.0
|
||||
|
||||
A JavaScript implementation of the http://semver.org/ specification
|
||||
Copyright Isaac Z. Schlueter
|
||||
|
||||
Usage: semver [options] <version> [<version> [...]]
|
||||
Prints valid versions sorted by SemVer precedence
|
||||
|
||||
Options:
|
||||
-r --range <range>
|
||||
Print versions that match the specified range.
|
||||
|
||||
-i --increment [<level>]
|
||||
Increment a version by the specified level. Level can
|
||||
be one of: major, minor, patch, premajor, preminor,
|
||||
prepatch, or prerelease. Default level is 'patch'.
|
||||
Only one version may be specified.
|
||||
|
||||
--preid <identifier>
|
||||
Identifier to be used to prefix premajor, preminor,
|
||||
prepatch or prerelease version increments.
|
||||
|
||||
-l --loose
|
||||
Interpret versions and ranges loosely
|
||||
|
||||
-c --coerce
|
||||
Coerce a string into SemVer if possible
|
||||
(does not imply --loose)
|
||||
|
||||
Program exits successfully if any valid version satisfies
|
||||
all supplied ranges, and prints all satisfying versions.
|
||||
|
||||
If no satisfying versions are found, then exits failure.
|
||||
|
||||
Versions are printed in ascending order, so supplying
|
||||
multiple versions to the utility will just sort them.
|
||||
```
|
||||
|
||||
## Versions
|
||||
|
||||
A "version" is described by the `v2.0.0` specification found at
|
||||
<http://semver.org/>.
|
||||
|
||||
A leading `"="` or `"v"` character is stripped off and ignored.
|
||||
|
||||
## Ranges
|
||||
|
||||
A `version range` is a set of `comparators` which specify versions
|
||||
that satisfy the range.
|
||||
|
||||
A `comparator` is composed of an `operator` and a `version`. The set
|
||||
of primitive `operators` is:
|
||||
|
||||
* `<` Less than
|
||||
* `<=` Less than or equal to
|
||||
* `>` Greater than
|
||||
* `>=` Greater than or equal to
|
||||
* `=` Equal. If no operator is specified, then equality is assumed,
|
||||
so this operator is optional, but MAY be included.
|
||||
|
||||
For example, the comparator `>=1.2.7` would match the versions
|
||||
`1.2.7`, `1.2.8`, `2.5.3`, and `1.3.9`, but not the versions `1.2.6`
|
||||
or `1.1.0`.
|
||||
|
||||
Comparators can be joined by whitespace to form a `comparator set`,
|
||||
which is satisfied by the **intersection** of all of the comparators
|
||||
it includes.
|
||||
|
||||
A range is composed of one or more comparator sets, joined by `||`. A
|
||||
version matches a range if and only if every comparator in at least
|
||||
one of the `||`-separated comparator sets is satisfied by the version.
|
||||
|
||||
For example, the range `>=1.2.7 <1.3.0` would match the versions
|
||||
`1.2.7`, `1.2.8`, and `1.2.99`, but not the versions `1.2.6`, `1.3.0`,
|
||||
or `1.1.0`.
|
||||
|
||||
The range `1.2.7 || >=1.2.9 <2.0.0` would match the versions `1.2.7`,
|
||||
`1.2.9`, and `1.4.6`, but not the versions `1.2.8` or `2.0.0`.
|
||||
|
||||
### Prerelease Tags
|
||||
|
||||
If a version has a prerelease tag (for example, `1.2.3-alpha.3`) then
|
||||
it will only be allowed to satisfy comparator sets if at least one
|
||||
comparator with the same `[major, minor, patch]` tuple also has a
|
||||
prerelease tag.
|
||||
|
||||
For example, the range `>1.2.3-alpha.3` would be allowed to match the
|
||||
version `1.2.3-alpha.7`, but it would *not* be satisfied by
|
||||
`3.4.5-alpha.9`, even though `3.4.5-alpha.9` is technically "greater
|
||||
than" `1.2.3-alpha.3` according to the SemVer sort rules. The version
|
||||
range only accepts prerelease tags on the `1.2.3` version. The
|
||||
version `3.4.5` *would* satisfy the range, because it does not have a
|
||||
prerelease flag, and `3.4.5` is greater than `1.2.3-alpha.7`.
|
||||
|
||||
The purpose for this behavior is twofold. First, prerelease versions
|
||||
frequently are updated very quickly, and contain many breaking changes
|
||||
that are (by the author's design) not yet fit for public consumption.
|
||||
Therefore, by default, they are excluded from range matching
|
||||
semantics.
|
||||
|
||||
Second, a user who has opted into using a prerelease version has
|
||||
clearly indicated the intent to use *that specific* set of
|
||||
alpha/beta/rc versions. By including a prerelease tag in the range,
|
||||
the user is indicating that they are aware of the risk. However, it
|
||||
is still not appropriate to assume that they have opted into taking a
|
||||
similar risk on the *next* set of prerelease versions.
|
||||
|
||||
#### Prerelease Identifiers
|
||||
|
||||
The method `.inc` takes an additional `identifier` string argument that
|
||||
will append the value of the string as a prerelease identifier:
|
||||
|
||||
```javascript
|
||||
semver.inc('1.2.3', 'prerelease', 'beta')
|
||||
// '1.2.4-beta.0'
|
||||
```
|
||||
|
||||
command-line example:
|
||||
|
||||
```bash
|
||||
$ semver 1.2.3 -i prerelease --preid beta
|
||||
1.2.4-beta.0
|
||||
```
|
||||
|
||||
Which then can be used to increment further:
|
||||
|
||||
```bash
|
||||
$ semver 1.2.4-beta.0 -i prerelease
|
||||
1.2.4-beta.1
|
||||
```
|
||||
|
||||
### Advanced Range Syntax
|
||||
|
||||
Advanced range syntax desugars to primitive comparators in
|
||||
deterministic ways.
|
||||
|
||||
Advanced ranges may be combined in the same way as primitive
|
||||
comparators using white space or `||`.
|
||||
|
||||
#### Hyphen Ranges `X.Y.Z - A.B.C`
|
||||
|
||||
Specifies an inclusive set.
|
||||
|
||||
* `1.2.3 - 2.3.4` := `>=1.2.3 <=2.3.4`
|
||||
|
||||
If a partial version is provided as the first version in the inclusive
|
||||
range, then the missing pieces are replaced with zeroes.
|
||||
|
||||
* `1.2 - 2.3.4` := `>=1.2.0 <=2.3.4`
|
||||
|
||||
If a partial version is provided as the second version in the
|
||||
inclusive range, then all versions that start with the supplied parts
|
||||
of the tuple are accepted, but nothing that would be greater than the
|
||||
provided tuple parts.
|
||||
|
||||
* `1.2.3 - 2.3` := `>=1.2.3 <2.4.0`
|
||||
* `1.2.3 - 2` := `>=1.2.3 <3.0.0`
|
||||
|
||||
#### X-Ranges `1.2.x` `1.X` `1.2.*` `*`
|
||||
|
||||
Any of `X`, `x`, or `*` may be used to "stand in" for one of the
|
||||
numeric values in the `[major, minor, patch]` tuple.
|
||||
|
||||
* `*` := `>=0.0.0` (Any version satisfies)
|
||||
* `1.x` := `>=1.0.0 <2.0.0` (Matching major version)
|
||||
* `1.2.x` := `>=1.2.0 <1.3.0` (Matching major and minor versions)
|
||||
|
||||
A partial version range is treated as an X-Range, so the special
|
||||
character is in fact optional.
|
||||
|
||||
* `""` (empty string) := `*` := `>=0.0.0`
|
||||
* `1` := `1.x.x` := `>=1.0.0 <2.0.0`
|
||||
* `1.2` := `1.2.x` := `>=1.2.0 <1.3.0`
|
||||
|
||||
#### Tilde Ranges `~1.2.3` `~1.2` `~1`
|
||||
|
||||
Allows patch-level changes if a minor version is specified on the
|
||||
comparator. Allows minor-level changes if not.
|
||||
|
||||
* `~1.2.3` := `>=1.2.3 <1.(2+1).0` := `>=1.2.3 <1.3.0`
|
||||
* `~1.2` := `>=1.2.0 <1.(2+1).0` := `>=1.2.0 <1.3.0` (Same as `1.2.x`)
|
||||
* `~1` := `>=1.0.0 <(1+1).0.0` := `>=1.0.0 <2.0.0` (Same as `1.x`)
|
||||
* `~0.2.3` := `>=0.2.3 <0.(2+1).0` := `>=0.2.3 <0.3.0`
|
||||
* `~0.2` := `>=0.2.0 <0.(2+1).0` := `>=0.2.0 <0.3.0` (Same as `0.2.x`)
|
||||
* `~0` := `>=0.0.0 <(0+1).0.0` := `>=0.0.0 <1.0.0` (Same as `0.x`)
|
||||
* `~1.2.3-beta.2` := `>=1.2.3-beta.2 <1.3.0` Note that prereleases in
|
||||
the `1.2.3` version will be allowed, if they are greater than or
|
||||
equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but
|
||||
`1.2.4-beta.2` would not, because it is a prerelease of a
|
||||
different `[major, minor, patch]` tuple.
|
||||
|
||||
#### Caret Ranges `^1.2.3` `^0.2.5` `^0.0.4`
|
||||
|
||||
Allows changes that do not modify the left-most non-zero digit in the
|
||||
`[major, minor, patch]` tuple. In other words, this allows patch and
|
||||
minor updates for versions `1.0.0` and above, patch updates for
|
||||
versions `0.X >=0.1.0`, and *no* updates for versions `0.0.X`.
|
||||
|
||||
Many authors treat a `0.x` version as if the `x` were the major
|
||||
"breaking-change" indicator.
|
||||
|
||||
Caret ranges are ideal when an author may make breaking changes
|
||||
between `0.2.4` and `0.3.0` releases, which is a common practice.
|
||||
However, it presumes that there will *not* be breaking changes between
|
||||
`0.2.4` and `0.2.5`. It allows for changes that are presumed to be
|
||||
additive (but non-breaking), according to commonly observed practices.
|
||||
|
||||
* `^1.2.3` := `>=1.2.3 <2.0.0`
|
||||
* `^0.2.3` := `>=0.2.3 <0.3.0`
|
||||
* `^0.0.3` := `>=0.0.3 <0.0.4`
|
||||
* `^1.2.3-beta.2` := `>=1.2.3-beta.2 <2.0.0` Note that prereleases in
|
||||
the `1.2.3` version will be allowed, if they are greater than or
|
||||
equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but
|
||||
`1.2.4-beta.2` would not, because it is a prerelease of a
|
||||
different `[major, minor, patch]` tuple.
|
||||
* `^0.0.3-beta` := `>=0.0.3-beta <0.0.4` Note that prereleases in the
|
||||
`0.0.3` version *only* will be allowed, if they are greater than or
|
||||
equal to `beta`. So, `0.0.3-pr.2` would be allowed.
|
||||
|
||||
When parsing caret ranges, a missing `patch` value desugars to the
|
||||
number `0`, but will allow flexibility within that value, even if the
|
||||
major and minor versions are both `0`.
|
||||
|
||||
* `^1.2.x` := `>=1.2.0 <2.0.0`
|
||||
* `^0.0.x` := `>=0.0.0 <0.1.0`
|
||||
* `^0.0` := `>=0.0.0 <0.1.0`
|
||||
|
||||
A missing `minor` and `patch` values will desugar to zero, but also
|
||||
allow flexibility within those values, even if the major version is
|
||||
zero.
|
||||
|
||||
* `^1.x` := `>=1.0.0 <2.0.0`
|
||||
* `^0.x` := `>=0.0.0 <1.0.0`
|
||||
|
||||
### Range Grammar
|
||||
|
||||
Putting all this together, here is a Backus-Naur grammar for ranges,
|
||||
for the benefit of parser authors:
|
||||
|
||||
```bnf
|
||||
range-set ::= range ( logical-or range ) *
|
||||
logical-or ::= ( ' ' ) * '||' ( ' ' ) *
|
||||
range ::= hyphen | simple ( ' ' simple ) * | ''
|
||||
hyphen ::= partial ' - ' partial
|
||||
simple ::= primitive | partial | tilde | caret
|
||||
primitive ::= ( '<' | '>' | '>=' | '<=' | '=' ) partial
|
||||
partial ::= xr ( '.' xr ( '.' xr qualifier ? )? )?
|
||||
xr ::= 'x' | 'X' | '*' | nr
|
||||
nr ::= '0' | ['1'-'9'] ( ['0'-'9'] ) *
|
||||
tilde ::= '~' partial
|
||||
caret ::= '^' partial
|
||||
qualifier ::= ( '-' pre )? ( '+' build )?
|
||||
pre ::= parts
|
||||
build ::= parts
|
||||
parts ::= part ( '.' part ) *
|
||||
part ::= nr | [-0-9A-Za-z]+
|
||||
```
|
||||
|
||||
## Functions
|
||||
|
||||
All methods and classes take a final `loose` boolean argument that, if
|
||||
true, will be more forgiving about not-quite-valid semver strings.
|
||||
The resulting output will always be 100% strict, of course.
|
||||
|
||||
Strict-mode Comparators and Ranges will be strict about the SemVer
|
||||
strings that they parse.
|
||||
|
||||
* `valid(v)`: Return the parsed version, or null if it's not valid.
|
||||
* `inc(v, release)`: Return the version incremented by the release
|
||||
type (`major`, `premajor`, `minor`, `preminor`, `patch`,
|
||||
`prepatch`, or `prerelease`), or null if it's not valid
|
||||
* `premajor` in one call will bump the version up to the next major
|
||||
version and down to a prerelease of that major version.
|
||||
`preminor`, and `prepatch` work the same way.
|
||||
* If called from a non-prerelease version, the `prerelease` will work the
|
||||
same as `prepatch`. It increments the patch version, then makes a
|
||||
prerelease. If the input version is already a prerelease it simply
|
||||
increments it.
|
||||
* `prerelease(v)`: Returns an array of prerelease components, or null
|
||||
if none exist. Example: `prerelease('1.2.3-alpha.1') -> ['alpha', 1]`
|
||||
* `major(v)`: Return the major version number.
|
||||
* `minor(v)`: Return the minor version number.
|
||||
* `patch(v)`: Return the patch version number.
|
||||
* `intersects(r1, r2, loose)`: Return true if the two supplied ranges
|
||||
or comparators intersect.
|
||||
|
||||
### Comparison
|
||||
|
||||
* `gt(v1, v2)`: `v1 > v2`
|
||||
* `gte(v1, v2)`: `v1 >= v2`
|
||||
* `lt(v1, v2)`: `v1 < v2`
|
||||
* `lte(v1, v2)`: `v1 <= v2`
|
||||
* `eq(v1, v2)`: `v1 == v2` This is true if they're logically equivalent,
|
||||
even if they're not the exact same string. You already know how to
|
||||
compare strings.
|
||||
* `neq(v1, v2)`: `v1 != v2` The opposite of `eq`.
|
||||
* `cmp(v1, comparator, v2)`: Pass in a comparison string, and it'll call
|
||||
the corresponding function above. `"==="` and `"!=="` do simple
|
||||
string comparison, but are included for completeness. Throws if an
|
||||
invalid comparison string is provided.
|
||||
* `compare(v1, v2)`: Return `0` if `v1 == v2`, or `1` if `v1` is greater, or `-1` if
|
||||
`v2` is greater. Sorts in ascending order if passed to `Array.sort()`.
|
||||
* `rcompare(v1, v2)`: The reverse of compare. Sorts an array of versions
|
||||
in descending order when passed to `Array.sort()`.
|
||||
* `diff(v1, v2)`: Returns difference between two versions by the release type
|
||||
(`major`, `premajor`, `minor`, `preminor`, `patch`, `prepatch`, or `prerelease`),
|
||||
or null if the versions are the same.
|
||||
|
||||
### Comparators
|
||||
|
||||
* `intersects(comparator)`: Return true if the comparators intersect
|
||||
|
||||
### Ranges
|
||||
|
||||
* `validRange(range)`: Return the valid range or null if it's not valid
|
||||
* `satisfies(version, range)`: Return true if the version satisfies the
|
||||
range.
|
||||
* `maxSatisfying(versions, range)`: Return the highest version in the list
|
||||
that satisfies the range, or `null` if none of them do.
|
||||
* `minSatisfying(versions, range)`: Return the lowest version in the list
|
||||
that satisfies the range, or `null` if none of them do.
|
||||
* `gtr(version, range)`: Return `true` if version is greater than all the
|
||||
versions possible in the range.
|
||||
* `ltr(version, range)`: Return `true` if version is less than all the
|
||||
versions possible in the range.
|
||||
* `outside(version, range, hilo)`: Return true if the version is outside
|
||||
the bounds of the range in either the high or low direction. The
|
||||
`hilo` argument must be either the string `'>'` or `'<'`. (This is
|
||||
the function called by `gtr` and `ltr`.)
|
||||
* `intersects(range)`: Return true if any of the ranges comparators intersect
|
||||
|
||||
Note that, since ranges may be non-contiguous, a version might not be
|
||||
greater than a range, less than a range, *or* satisfy a range! For
|
||||
example, the range `1.2 <1.2.9 || >2.0.0` would have a hole from `1.2.9`
|
||||
until `2.0.0`, so the version `1.2.10` would not be greater than the
|
||||
range (because `2.0.1` satisfies, which is higher), nor less than the
|
||||
range (since `1.2.8` satisfies, which is lower), and it also does not
|
||||
satisfy the range.
|
||||
|
||||
If you want to know if a version satisfies or does not satisfy a
|
||||
range, use the `satisfies(version, range)` function.
|
||||
|
||||
### Coercion
|
||||
|
||||
* `coerce(version)`: Coerces a string to semver if possible
|
||||
|
||||
This aims to provide a very forgiving translation of a non-semver
|
||||
string to semver. It looks for the first digit in a string, and
|
||||
consumes all remaining characters which satisfy at least a partial semver
|
||||
(e.g., `1`, `1.2`, `1.2.3`) up to the max permitted length (256 characters).
|
||||
Longer versions are simply truncated (`4.6.3.9.2-alpha2` becomes `4.6.3`).
|
||||
All surrounding text is simply ignored (`v3.4 replaces v3.3.1` becomes `3.4.0`).
|
||||
Only text which lacks digits will fail coercion (`version one` is not valid).
|
||||
The maximum length for any semver component considered for coercion is 16 characters;
|
||||
longer components will be ignored (`10000000000000000.4.7.4` becomes `4.7.4`).
|
||||
The maximum value for any semver component is `Integer.MAX_SAFE_INTEGER || (2**53 - 1)`;
|
||||
higher value components are invalid (`9999999999999999.4.7.4` is likely invalid).
|
||||
151
website/node_modules/npm/doc/spec/file-specifiers.md
generated
vendored
Normal file
151
website/node_modules/npm/doc/spec/file-specifiers.md
generated
vendored
Normal file
@@ -0,0 +1,151 @@
|
||||
# `file:` specifiers
|
||||
|
||||
`specifier` refers to the value part of the `package.json`'s `dependencies`
|
||||
object. This is a semver expression for registry dependencies and
|
||||
URLs and URL-like strings for other types.
|
||||
|
||||
### Dependency Specifiers
|
||||
|
||||
* A `file:` specifier is either an absolute path (eg `/path/to/thing`, `d:\path\to\thing`):
|
||||
* An absolute `file:///absolute/path` with any number of leading slashes
|
||||
being treated as a single slash. That is, `file:/foo/bar` and
|
||||
`file:///foo/bar` reference the same package.
|
||||
* … or a relative path (eg `../path/to/thing`, `path\to\subdir`). Leading
|
||||
slashes on a file specifier will be removed, that is 'file://../foo/bar`
|
||||
references the same package as same as `file:../foo/bar`. The latter is
|
||||
considered canonical.
|
||||
* Attempting to install a specifier that has a windows drive letter will
|
||||
produce an error on non-Windows systems.
|
||||
* A valid `file:` specifier points is:
|
||||
* a valid package file. That is, a `.tar`, `.tar.gz` or `.tgz` containing
|
||||
`<dir>/package.json`.
|
||||
* OR, a directory that contains a `package.json`
|
||||
|
||||
Relative specifiers are relative to the file they were found in, or, if
|
||||
provided on the command line, the CWD that the command was run from.
|
||||
|
||||
An absolute specifier found in a `package.json` or `npm-shrinkwrap.json` is
|
||||
probably an error as it's unlikely to be portable between computers and
|
||||
should warn.
|
||||
|
||||
A specifier provided as a command line argument that is on a different drive
|
||||
is an error. That is, `npm install file:d:/foo/bar` is an error if the
|
||||
current drive is `c`. The point of this rule is that if we can't produce a
|
||||
relative path then it's an error.
|
||||
|
||||
### Specifier Disambiguation
|
||||
|
||||
On the command line, plain paths are allowed. These paths can be ambiguous
|
||||
as they could be a path, a plain package name or a github shortcut. This
|
||||
ambiguity is resolved by checking to see if either a directory exists that
|
||||
contains a `package.json`. If either is the case then the specifier is a
|
||||
file specifier, otherwise it's a registry or github specifier.
|
||||
|
||||
### Specifier Matching
|
||||
|
||||
A specifier is considered to match a dependency on disk when the `realpath`
|
||||
of the fully resolved specifier matches the `realpath` of the package on disk.
|
||||
|
||||
### Saving File Specifiers
|
||||
|
||||
When saving to both `package.json` and `npm-shrinkwrap.json` they will be
|
||||
saved using the `file:../relative/path` form, and the relative path will be
|
||||
relative to the project's root folder. This is particularly important to
|
||||
note for the `npm-shrinkwrap.json` as it means the specifier there will
|
||||
be different then the original `package.json` (where it was relative to that
|
||||
`package.json`).
|
||||
|
||||
When shrinkwrapping file specifiers, the contents of the destination
|
||||
package's `node_modules` WILL NOT be included in the shrinkwrap. If you want to lock
|
||||
down the destination package's `node_modules` you should create a shrinkwrap for it
|
||||
separately.
|
||||
|
||||
This is necessary to support the mono repo use case where many projects file
|
||||
to the same package. If each project included its own `npm-shrinkwrap.json`
|
||||
then they would each have their own distinct set of transitive dependencies
|
||||
and they'd step on each other any time you ran an install in one or the other.
|
||||
|
||||
NOTE: This should not have an effect on shrinkwrapping of other sorts of
|
||||
shrinkwrapped packages.
|
||||
|
||||
### Installation
|
||||
|
||||
#### File type specifiers pointing at tarballs
|
||||
|
||||
File-type specifiers pointing at a `.tgz` or `.tar.gz` or `.tar` file will
|
||||
install it as a package file in the same way we would a remote tarball. The
|
||||
checksum of the package file should be recorded so that we can check for updates.
|
||||
|
||||
#### File type specifers pointing at directories
|
||||
|
||||
File-type specifiers that point at directories will necessarily not do
|
||||
anything for `fetch` and `extract` phases.
|
||||
|
||||
The symlink should be created during the `finalize` phase.
|
||||
|
||||
The `preinstall` for file-type specifiers MUST be run AFTER the
|
||||
`finalize` phase as the symlink may be a relative path reaching outside the
|
||||
current project root and a symlink that resolves in `.staging` won't resolve
|
||||
in the package's final resting place.
|
||||
|
||||
If the module is inside the package root that we're running the install for then
|
||||
dependencies of the linked package will be hoisted to the top level as usual.
|
||||
|
||||
If the module is outside the package root then dependencies will be installed inside
|
||||
the linked module's `node_modules` folder.
|
||||
|
||||
### Removal
|
||||
|
||||
Removal should remove the symlink.
|
||||
|
||||
Removal MUST NOT remove the transitive dependencies IF they're installed in
|
||||
the linked module's `node_modules` folder.
|
||||
|
||||
### Listing
|
||||
|
||||
In listings they should not include a version as the version is not
|
||||
something `npm` is concerned about. This also makes them easily
|
||||
distinguishable from symlinks of packages that have other dependency
|
||||
specifiers.
|
||||
|
||||
If you had run:
|
||||
|
||||
```
|
||||
npm install --save file:../a
|
||||
```
|
||||
|
||||
And then run:
|
||||
```
|
||||
npm ls
|
||||
```
|
||||
|
||||
You would see:
|
||||
|
||||
```
|
||||
example-package@1.0.0 /path/to/example-package
|
||||
└── a → file:../a
|
||||
```
|
||||
|
||||
```
|
||||
example-package@1.0.0 /path/to/example-package
|
||||
+-- a -> file:../a
|
||||
```
|
||||
|
||||
Of note here: No version is included as the relevant detail is WHERE the
|
||||
package came from, not what version happened to be in that path.
|
||||
|
||||
### Outdated
|
||||
|
||||
Local specifiers should only show up in `npm outdated` if they're missing
|
||||
and when they do, they should be reported as:
|
||||
|
||||
```
|
||||
Package Current Wanted Latest Location
|
||||
a MISSING LOCAL LOCAL example-package
|
||||
```
|
||||
|
||||
### Updating
|
||||
|
||||
If a dependency with a local specifier is already installed then `npm
|
||||
update` shouldn't do anything. If one is missing then it should be
|
||||
installed as if you ran `npm install`.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user