16

I've searched through other questions such as this one, but they all seem to be about a local npm link stopping working for another reason than mine. I assume this is a common use-case issue, so if I'm doing something methodically wrong, I'm more than happy to take suggestions on how I should be doing it.

Principally, I have a private npm module that I'm working on called @organisation/module. When working locally, I'll run npm link on it, and use it within my 'host' project as npm link @organisation/module — this all works great with hot-reloading, etc. I'll also import it as import module from '@organisation/module.

However, since I also want to publish my local changes to npm (as @organisation/module) from time to time, for build testing and production code, I need to run npm install @organisation/module on the host project.

This then seems to break the implicit npm link I set up earlier... I assume mainly because they are the same name, and npm favors an install over a link?

When I want to make live, local changes again, the only way I can currently get it to work is via npm uninstall @organisation/module and then to re-link it.

Is there a way to keep the published module installed (in order to avoid careless mistakes, like forgetting to reinstall it for build testing), but always favour the local, linked instance?

Diagram for ref: Diagram for ref

Sarreph
  • 1,986
  • 2
  • 19
  • 41
  • 1
    Update — I've ended up writing a bash / npm script combo that puts these manual unlinking / re-installing into a semi-automatic state... Still would like to know if there's something that can be statically assigned in npm to do this though! – Sarreph Oct 02 '18 at 18:59

3 Answers3

4

Have you tried locally installing with the other method npm provides.

npm install /absolute/path/packageName

I believe this will change your entry in package.json to look like this:

"dependencies" {
    ...
    "packageName": "file:../../path/to/packageName",
    ...
}
  • 3
    The thing is, this works, but now anybody who pulls my code and tries to `npm install` it will get an error if they haven't first pulled the dependency into `../../module/`. The common case of "pull the code, run `npm install`, project Just Works" should still be supported. – Coderer Aug 22 '19 at 13:07
  • 1
    @Coderer I gotcha, you could also try to link it to your git repo: `npm install --save https://github.com/{USER}/{REPO}/tarball/{BRANCH}` – AndrewSteinheiser Jun 26 '20 at 16:47
1

Since npm link creates a symlink in the global folder, while npm install is local to the project npm install takes precedence. You can read about npm link here: https://docs.npmjs.com/cli/link

To avoid this, my suggestion would be to use npm install <path to local> and when you need to use the production code use npm install @organization/module. This would update your node_modules per code basis. Read about npm install here: https://docs.npmjs.com/cli/install

Hope this helps :)

dRoyson
  • 1,466
  • 3
  • 14
  • 25
-1
  1. Go to the directory where your local package is located open package.json change the name from original_name to "original_name_local".

  2. write npm link on terminal at the same location.

  3. After this go to your working directory and write npm install <path to local>

  4. Now whereever you're requiring or importing update the name to "original_name_local"

for example if it's require('space-cleaner') then change it to require('space-cleaner_local')

Like this you can have both local as well as production package just change the name wherever required.

Otherwise you can remove package by removing it from package.json and deleting from node_modules.

if local is needed go to local package directory and on terminal write npm link and then on your working directory write npm install ./path/to/package

if production then again delete the package as told above and write npm install package_name

Atishay Jain
  • 1,425
  • 12
  • 22
  • 2
    The whole point of this question is to seamlessly develop against the local copy of the module while allowing others to pull and build your package using the published version of the module. Manually changing your code is labor intensive and error prone. – Coderer Aug 22 '19 at 13:08