1 ---
2 title: npm-link
3 section: 1
4 description: Symlink a package folder
5 github_repo: npm/cli
6 github_branch: latest
7 github_path: docs/lib/content/commands/npm-link.md
8 redirect_from:
9 - /cli-commands/link
10 - /cli-commands/npm-link
11 - /cli-documentation/cli-commands/link
12 - /cli-documentation/cli-commands/npm-link
13 - /cli-documentation/commands/link
14 - /cli-documentation/commands/npm-link
15 - /cli-documentation/link
16 - /cli-documentation/npm-link
17 - /cli-documentation/v11/cli-commands/link
18 - /cli-documentation/v11/cli-commands/npm-link
19 - /cli-documentation/v11/commands/link
20 - /cli-documentation/v11/commands/npm-link
21 - /cli-documentation/v11/link
22 - /cli-documentation/v11/npm-link
23 - /cli/cli-commands/link
24 - /cli/cli-commands/npm-link
25 - /cli/commands/link
26 - /cli/commands/npm-link
27 - /cli/link
28 - /cli/npm-link
29 - /cli/v11/cli-commands/link
30 - /cli/v11/cli-commands/npm-link
31 - /cli/v11/commands/link
32 - /cli/v11/link
33 - /cli/v11/npm-link
34 - /commands/link
35 - /commands/npm-link
36 ---
37
38 ### Synopsis
39
40 ```bash
41 npm link [<package-spec>]
42
43 alias: ln
44 ```
45
46 ### Description
47
48 This is handy for installing your own stuff, so that you can work on it and test iteratively without having to continually rebuild.
49
50 Package linking is a two-step process.
51
52 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).
53
54 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.
55
56 Note that `package-name` is taken from `package.json`, _not_ from the directory name.
57
58 The package name can be optionally prefixed with a scope. See [`scope`](/cli/v11/using-npm/scope). The scope must be preceded by an @-symbol and followed by a slash.
59
60 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`.
61
62 For example:
63
64 ```bash
65 cd ~/projects/node-redis # go into the package directory
66 npm link # creates global link
67 cd ~/projects/node-bloggy # go into some other package directory.
68 npm link redis # link-install the package
69 ```
70
71 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.
72
73 You may also shortcut the two steps in one. For example, to do the above use-case in a shorter way:
74
75 ```bash
76 cd ~/projects/node-bloggy # go into the dir of your main project
77 npm link ../node-redis # link the dir of your dependency
78 ```
79
80 The second line is the equivalent of doing:
81
82 ```bash
83 (cd ../node-redis; npm link)
84 npm link redis
85 ```
86
87 That is, it first creates a global link, and then links the global installation target into your project's `node_modules` folder.
88
89 Note that in this case, you are referring to the directory name, `node-redis`, rather than the package name `redis`.
90
91 If your linked package is scoped (see [`scope`](/cli/v11/using-npm/scope)) your link command must include that scope, e.g.
92
93 ```bash
94 npm link @myorg/privatepackage
95 ```
96
97 ### Caveat
98
99 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.
100
101 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`.
102
103 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.
104
105 ### Workspace Usage
106
107 `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.
108
109 `npm link --workspace <name>` will create a global link to the specified workspace(s).
110
111 ### Configuration
112
113 #### `save`
114
115 - Default: `true` unless when using `npm update` where it defaults to `false`
116 - Type: Boolean
117
118 Save installed packages to a `package.json` file as dependencies.
119
120 When used with the `npm rm` command, removes the dependency from `package.json`.
121
122 Will also prevent writing to `package-lock.json` if set to `false`.
123
124 #### `save-exact`
125
126 - Default: false
127 - Type: Boolean
128
129 Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
130
131 #### `global`
132
133 - Default: false
134 - Type: Boolean
135
136 Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
137
138 - packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
139 - bin files are linked to `{prefix}/bin`
140 - man pages are linked to `{prefix}/share/man`
141
142 #### `install-strategy`
143
144 - Default: "hoisted"
145 - Type: "hoisted", "nested", "shallow", or "linked"
146
147 Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
148
149 #### `legacy-bundling`
150
151 - Default: false
152 - Type: Boolean
153 - DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
154
155 Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
156
157 #### `global-style`
158
159 - Default: false
160 - Type: Boolean
161 - DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
162
163 Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
164
165 #### `strict-peer-deps`
166
167 - Default: false
168 - Type: Boolean
169
170 If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
171
172 By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
173
174 When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
175
176 #### `package-lock`
177
178 - Default: true
179 - Type: Boolean
180
181 If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
182
183 #### `omit`
184
185 - Default: 'dev' if the `NODE_ENV` environment variable is set to 'production'; otherwise, empty.
186 - Type: "dev", "optional", or "peer" (can be set multiple times)
187
188 Dependency types to omit from the installation tree on disk.
189
190 Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
191
192 If a package type appears in both the `--include` and `--omit` lists, then it will be included.
193
194 If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
195
196 #### `include`
197
198 - Default:
199 - Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
200
201 Option that allows for defining which types of dependencies to install.
202
203 This is the inverse of `--omit=<type>`.
204
205 Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
206
207 #### `ignore-scripts`
208
209 - Default: false
210 - Type: Boolean
211
212 If true, npm does not run scripts specified in package.json files.
213
214 Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
215
216 #### `allow-git`
217
218 - Default: "all"
219 - Type: "all", "none", or "root"
220
221 Limits the ability for npm to fetch dependencies from git references. That is, dependencies that point to a git repo instead of a version or semver range. Please note that this could leave your tree incomplete and some packages may not function as intended or designed.
222
223 `all` allows any git dependencies to be fetched and installed. `none` prevents any git dependencies from being fetched and installed. `root` only allows git dependencies defined in your project's package.json to be fetched installed. Also allows git dependencies to be fetched for other commands like `npm view`
224
225 #### `audit`
226
227 - Default: true
228 - Type: Boolean
229
230 When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
231
232 #### `bin-links`
233
234 - Default: true
235 - Type: Boolean
236
237 Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
238
239 Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
240
241 #### `fund`
242
243 - Default: true
244 - Type: Boolean
245
246 When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
247
248 #### `dry-run`
249
250 - Default: false
251 - Type: Boolean
252
253 Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
254
255 Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
256
257 #### `workspace`
258
259 - Default:
260 - Type: String (can be set multiple times)
261
262 Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
263
264 Valid values for the `workspace` config are either:
265
266 - Workspace names
267 - Path to a workspace directory
268 - Path to a parent workspace directory (will result in selecting all workspaces within that folder)
269
270 When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
271
272 This value is not exported to the environment for child processes.
273
274 #### `workspaces`
275
276 - Default: null
277 - Type: null or Boolean
278
279 Set to true to run the command in the context of **all** configured workspaces.
280
281 Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
282
283 - Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
284
285 This value is not exported to the environment for child processes.
286
287 #### `include-workspace-root`
288
289 - Default: false
290 - Type: Boolean
291
292 Include the workspace root when workspaces are enabled for a command.
293
294 When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
295
296 This value is not exported to the environment for child processes.
297
298 #### `install-links`
299
300 - Default: false
301 - Type: Boolean
302
303 When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
304
305 ### See Also
306
307 - [package spec](/cli/v11/using-npm/package-spec)
308 - [npm developers](/cli/v11/using-npm/developers)
309 - [package.json](/cli/v11/configuring-npm/package-json)
310 - [npm install](/cli/v11/commands/npm-install)
311 - [npm folders](/cli/v11/configuring-npm/folders)
312 - [npm config](/cli/v11/commands/npm-config)
313 - [npmrc](/cli/v11/configuring-npm/npmrc)