From 7865c5c51dc6ef2f17644b4923ea451da21eee5a Mon Sep 17 00:00:00 2001
From: Marcel Laverdet
Node Hispano Spanish language community
+ Node.js EspaƱol Node.js in Spanish
+
OctoberSkyJs Korea Node.js community
Manage package owners
- -npm.commands.owner(args, callback)
-
-The first element of the 'args' parameter defines what to do, and the subsequent -elements depend on the action. Possible values for the action are (order of -parameters are given in parenthesis):
- -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.
- -This function should not be used programmatically. Instead, just refer
to the npm.bin member.
Manage the npm configuration files
- -npm.commands.config(args, callback)
-var val = npm.config.get(key)
-npm.config.set(key, val)
-
-This function acts much the same way as the command-line version. The first -element in the array tells config what to do. Possible values are:
- -set
Sets a config parameter. The second element in args is interpreted as the
-key, and the third element is interpreted as the value.
get
Gets the value of a config parameter. The second element in args is the
-key to get the value of.
delete (rm or del)
Deletes a parameter from the config. The second element in args is the
-key to delete.
list (ls)
Show all configs that aren't secret. No parameters necessary.
edit:
Opens the config file in the default editor. This command isn't very useful -programmatically, but it is made available.
To programmatically access npm configuration settings, or set them for
-the duration of a program, use the npm.config.set and npm.config.get
-functions instead.
The silent parameter is not neccessary not used, but it may in the future.
Symlink a package folder
- -npm.command.link(callback)
-npm.command.link(packages, callback)
-
-Package linking is a two-step process.
- -Without parameters, link will create a globally-installed
-symbolic link from prefix/package-name to the current folder.
With a parameters, link will create a symlink from the local node_modules
-folder to the global symlink.
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:
- -npm.commands.link(cb) # creates global link from the cwd
- # (say redis package)
-npm.commands.link('redis', cb) # link-install the package
-
-Now, any changes to the redis package will be reflected in -the package in the current working directory
-For a list of all the available command-line configs, see npm help config
This function is not useful programmatically.
Finally, 'callback' is a function that will be called when the shrinkwrap has been saved.
json(1)faq(1) json(1) install(1) pack(1) cache(1) config(1) publish(1)
Folder Structures Used by npm
- -npm puts various things on your computer. That's its job.
- -This document will tell you what it puts where.
- -./node_modules of the current
-package root.-g): puts stuff in /usr/local or wherever node
-is installed.require() it.npm link.The prefix config defaults to the location where node is installed.
-On most systems, this is /usr/local, and most of the time is the same
-as node's process.installPrefix.
On windows, this is the exact location of the node.exe binary. 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.
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.)
If you wish to require() a package, then install it locally.
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.)
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.
- -See cache(1). Cache files are stored in ~/.npm on Posix, or
-~/npm-cache on Windows.
This is controlled by the cache configuration param.
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.
- -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 cded
-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.
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 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.
- -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 satisfie's 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.
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 json(1) for more information.
Display npm username
List installed packages
- -npm list
-npm ls
-npm la
-npm ll
-
-This command will print to stdout all the versions of packages that are -installed, as well as their dependencies, in a tree-structure.
- -It does not take positional arguments, though you may set config flags
-like with any other command, such as -g to list global packages.
It will print out extraneous, missing, and invalid packages.
- -When run as ll or la, it shows extended information by default.
Show extended information.
- -Show parseable output instead of tree view.
- -List packages in the global install prefix instead of in the current -project.
- -1.1.21
+1.1.24