Man page - npm-link(1)
Packages contains this manual
- npm-root(1)
- npm-explain(1)
- npm-whoami(1)
- npm-pack(1)
- npm-bugs(1)
- npm-view(1)
- npm-outdated(1)
- npm-update(1)
- npm-query(1)
- npm-logout(1)
- npm-deprecate(1)
- npm-exec(1)
- npm-ping(1)
- npm-shrinkwrap-json(5)
- npm-help(1)
- npm-prefix(1)
- npm-diff(1)
- npm-owner(1)
- npm-install(1)
- npmrc(5)
- npm-uninstall(1)
- npm-hook(1)
- npm-unstar(1)
- npm-docs(1)
- pacote(1)
- npm-restart(1)
- npm-star(1)
- npm-link(1)
- npm-test(1)
- npm-token(1)
- npm-arborist(1)
- npm-profile(1)
- npm-team(1)
- npx(1)
- npm-stars(1)
- npm-adduser(1)
- npm-cache(1)
- npm-edit(1)
- npm-doctor(1)
- npm-help-search(1)
- arborist(1)
- npm-rebuild(1)
- npm-repo(1)
- npm-publish(1)
- npm-start(1)
- npm-unpublish(1)
- npm-dedupe(1)
- npm-init(1)
- npm-dist-tag(1)
- npm-login(1)
- npm-config(1)
- npm(1)
- npm-search(1)
- npm-version(1)
- npm-org(1)
- npm-shrinkwrap(1)
- npm-ls(1)
- package-json(5)
- npm-stop(1)
- npm-install-test(1)
- npm-completion(1)
- npm-run-script(1)
- npm-prune(1)
- npm-access(1)
- npm-ci(1)
- npm-audit(1)
- npm-find-dupes(1)
- npm-install-ci-test(1)
- package-lock-json(5)
- npm-fund(1)
- npm-explore(1)
- npm-pkg(1)
- node-pacote
- node-npmcli-mock-registry
- node-npmcli-node-gyp
- node-libnpmorg
- npm
- node-libnpmteam
- node-npmcli-promise-spawn
- node-libnpmdiff
- node-npmcli-run-script
- node-npmcli-metavuln-calculator
- node-npmcli-smoke-tests
- node-libnpmpublish
- node-qrcode-terminal
- node-npmcli-config
- node-npmcli-git
- node-libnpmaccess
- node-npm-packlist
- node-npmcli-disparity-colors
- node-libnpmexec
- node-npmcli-installed-package-contents
- node-libnpmpack
- node-npmcli-map-workspaces
- node-npmcli-query
- node-npmcli-arborist
- node-npmcli-package-json
- node-libnpmhook
- node-npmcli-name-from-folder
- node-libnpmversion
- node-libnpmfund
- node-libnpmsearch
apt-get install npm
Manual
NPM-LINK
NAMESynopsis
Description
Caveat
Workspace Usage
Configuration
See Also
NAME
npm-link
Synopsis
<!-- AUTOGENERATED USAGE DESCRIPTIONS -->
Description
This is handy
for installing your own stuff, so that you can work on it
and
test iteratively without having to continually rebuild.
Package linking is a two-step process.
First,
npm
link
in a package folder with no arguments 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. It will
also link any bins in the package to
{prefix}/bin/{name}
. Note that
npm link
uses the global prefix (see
npm prefix
-g
for its value).
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 the
directory name.
The package name
can be optionally prefixed with a scope. See
scope
. 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, if
they are included in
bundleDependencies
.
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
scope
) your
link command must include that scope, e.g.
npm link @myorg/privatepackage
Caveat
Note that
package dependencies linked in this way are
not
saved
to
package.json
by default, on the assumption that the
intention is to have
a link stand in for a regular non-link dependency.
Otherwise, for example,
if you depend on
redis@ˆ3.0.1
, and ran
npm
link redis
, it would replace
the
ˆ3.0.1
dependency with
file:../path/to/node-redis
, which you
probably don’t want! Additionally, other users or
developers on your
project would run into issues if they do not have their
folders set up
exactly the same as yours.
If you are
adding a
new
dependency as a link, you should add it
to the
relevant metadata by running
npm install <dep>
--package-lock-only
.
If you
want
to save the
file:
reference in your
package.json
and
package-lock.json
files, you can use
npm link
<dep> --save
to do so.
Workspace Usage
npm link
<pkg> --workspace <name>
will link the
relevant package as a
dependency of the specified workspace(s). Note that It may
actually be
linked into the parent project’s
node_modules
folder, if there are no
conflicting dependencies.
npm link
--workspace <name>
will create a global link to
the specified
workspace(s).
Configuration
<!-- AUTOGENERATED CONFIG DESCRIPTIONS -->
See Also
|
• |
package spec |
|||
|
• |
npm developers |
|||
|
• |
package.json |
|||
|
• |
npm install |
|||
|
• |
npm folders |
|||
|
• |
npm config |
|||
|
• |
npmrc |