From 43dd49c9782848c25e5b03448c8a0f923f13c158 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kat=20March=C3=A1n?=
Use named functions. They make stack traces a lot easier to read.
-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 @@ -110,7 +110,7 @@ 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".
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").
NO_COLOR
is set to any value
since that gives more useful information. To show the outdated status
of all packages and dependents, use a large integer value,
e.g., npm outdated --depth 9999
-The commit-ish
can be any tag, sha, or branch which can be supplied as
an argument to git checkout
. The default is master
.
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
@@ -198,5 +198,5 @@ from a fresh checkout.
npm owner ls <pkgname>
Don't squat on package names. Publish code or move out of the way.
@@ -58,13 +58,13 @@ because Yusuf'sfoo
is in the way.
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
+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.
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 +support@npmjs.com and we'll sort it out. ("Reasonable" is usually at least 4 weeks.)
If you see bad behavior like this, please report it to abuse@npmjs.com right +
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.
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 +using a confusingly similar package name, email abuse@npmjs.com with a link to the package or user account on 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 @@ -139,5 +139,5 @@ License.
Index of all npm documentation
-a JavaScript package manager
Using npm on the command line
-javascript package manager
-Set access level on published packages
-Add a registry user account
-Run a security audit
-Display npm bin folder
-Bugs for a package in a web browser maybe
-Build a package
-REMOVED
-Manipulates packages cache
-Install a project with a clean slate
-Tab Completion for npm
-Manage the npm configuration files
-Reduce duplication
-Deprecate a version of a package
-Modify package distribution tags
-Docs for a package in a web browser maybe
-Check your environments
-Edit an installed package
-Browse an installed package
-Search npm help documentation
-Get help on npm
-Manage registry hooks
-create a package.json file
-Install a project with a clean slate and run tests
-Install package(s) and run tests
-Install a package
-Symlink a package folder
-Log out of the registry
-List installed packages
-Manage orgs
+Check for outdated packages
-Manage package owners
-Create a tarball from a package
-Ping npm registry
-Display prefix
-Change settings on your registry profile
-Remove extraneous packages
-Publish a package
-Rebuild a package
-Open package repository page in the browser
-Restart a package
-Display npm root
-Run arbitrary package scripts
-Search for packages
-Lock down dependency versions for publication
-Mark your favorite packages
-View packages marked as favorites
-Start a package
-Stop a package
-Manage organization teams and team memberships
-Test a package
-Manage your authentication tokens
-Remove a package
-Remove a package from the registry
-Update a package
-Bump a package version
-View registry info
-Display npm username
Using npm in your Node programs
File system structures npm uses
-Folder Structures Used by npm
-An explanation of npm lockfiles
-A publishable lockfile
-The npm config files
-A manifestation of the manifest
-Specifics of npm's package.json handling
Various other bits and bobs
-npm's "funny" coding style
-More than you probably want to know about npm configuration
-Developer Guide
-Handling Module Name Disputes
-Index of all npm documentation
-Working with Teams & Orgs
-The JavaScript Package Registry
-Scoped packages
-How npm handles the "scripts" field
-Cleaning the Slate
-The semantic versioner for npm
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.
-Yes.
When making requests of the registry npm adds two headers with information about your environment:
@@ -51,7 +51,7 @@ 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.
-Yes!
The easiest way is to replicate the couch database, and use the same (or similar) design doc to implement the APIs.
@@ -61,20 +61,20 @@ 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.
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.
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.
-No, but it's way easier. Basically, yes, you do, or you have to effectively implement the entire CouchDB API anyway.
-Yes, head over to https://www.npmjs.com/
then you could run npm start
to execute the bar
script, which is
exported into the node_modules/.bin
directory on npm install
.
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
@@ -139,7 +139,7 @@ in your code with process.env.npm_package_name
and
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.
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:
The semantic versioner for npm
npm install --save semver
-`
+npm install --save semver
As a node module:
const semver = require('semver')
@@ -28,8 +27,6 @@ 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
@@ -53,6 +50,9 @@ Options:
-l --loose
Interpret versions and ranges loosely
+-p --include-prerelease
+ Always include prerelease versions in range matching
+
-c --coerce
Coerce a string into SemVer if possible
(does not imply --loose)
@@ -133,7 +133,7 @@ will append the value of the string as a prerelease identifier:
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
+Hyphen Ranges X.Y.Z - A.B.C
Specifies an inclusive set.
1.2.3 - 2.3.4
:= >=1.2.3 <=2.3.4
@@ -151,7 +151,7 @@ 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.*
*
+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.
@@ -166,7 +166,7 @@ character is in fact optional.
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
+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.
@@ -182,7 +182,7 @@ equal to beta.2
. So, 1.2.3-beta.4
would be allowed, b
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
+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
@@ -242,9 +242,20 @@ 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.
+All methods and classes take a final options
object argument. All
+options in this object are false
by default. The options supported
+are:
+
+loose
Be more forgiving about not-quite-valid semver strings.
+(Any resulting output will always be 100% strict compliant, of
+course.) For backwards compatibility reasons, if the options
+argument is a boolean value instead of an object, it is interpreted
+to be the loose
param.
+includePrerelease
Set to suppress the default
+behavior of
+excluding prerelease tagged versions from ranges unless they are
+explicitly opted into.
+
Strict-mode Comparators and Ranges will be strict about the SemVer
strings that they parse.
@@ -295,7 +306,7 @@ or null if the versions are the same.
intersects(comparator)
: Return true if the comparators intersect
-Ranges
+Ranges
validRange(range)
: Return the valid range or null if it's not valid
satisfies(version, range)
: Return true if the version satisfies the
@@ -350,5 +361,5 @@ higher value components are invalid (9999999999999999.4.7.4
is like
-
+
--
cgit v1.2.3