0

I have a package which resides in a subfolder of another package (or anywhere locally), and the parent package now needs to install it:

main
 ├──node_modules
 ├──otherProject
 │   ├──node_modules
 │   ├──index.js
 │   └──package.json
 ├──package.json
 └──something.anything

The files (apart from node_modules and other common items) are from version control. Is there a way to do this on windows 7/8/10 without elevated permissions, that works "out of the box"?

On linux this would be a simple npm install ./otherProject.

While not too relevant, i'll add that this is a custom eslint plugin. Maybe someone has a tip that solves the specific situation, but isn't generalizable.

A short summary of the issues:

  • To create symlinks on windows, the process needs administrator permissions, or developer mode on windows 10. I'd not count either as "out of the box", a build needing administrator or special OS-flags is a non-solution. This means neither npm install <folder> nor npm link work, as both create symlinks.

  • An alternative is creating a tarball, and installing that. First of all, this introduces an unnecessary copy, which complicates making changes to the package. Secondly, this tarball needs to be created, before installation, but preinstall for mythical reasons is still not done first. Updating fails, as it tries to resolve the file, before preinstall generated it.

I don't see any of the solutions in e.g. this question to apply. This answer helped with the tarball approach, which is also now stuck. I hope i am just misunderstanding something, or making a simple mistake.

Doofus
  • 952
  • 4
  • 19

1 Answers1

1

I think is a bad practice to reference a module from another folder to production.

I recommend you have a different folder for each project:

main
 ├──mainProject
 │   ├──node_modules
 │   ├──package.json
 │   └──something.anything
 ├──otherProject
 │   ├──node_modules
 │   ├──index.js
 │   └──package.json
 └──otherProject-1.0.0.tgz // This file is created by node...

So first you package the other project and install it in your main project

main> npm pack otherProject
main> cd mainProject
main\mainProject> npm install --save ../otherProject-1.0.0.tgz

You would have more control and your solution will be cleaner.

NOTE: If you don't change the version in package.json in otherProject when you make any change and pack it you will have the previous version.

In case you want to keep the version in package.json you could clean the cache of npm with:

npm cache clean --force
jtwalters
  • 1,024
  • 7
  • 25
  • Thanks, but a few questions: What's the reason to not have `otherProject` as a subfolder? The described approach works either way. Then, using an intermediate tarball manually is possible, but if the project is obtained from git (or a similar source), a `npm i` will fail, as `otherProject-1.0.0.tgz` won't exist (it's a generated file, not in git). As mentioned, `preinstall` isn't early enough to work here as far as i can see. My current plan is attaching a rather complex build-script to a git-hook (needs to hash files and more), but i'd have much preferred not breaking `npm i`. – Doofus Jan 17 '21 at 13:04
  • PS: a few mentions, which shouldn't be too important, but might give more context: the output from the entire project is a website, the package not intended for use as a dependency. As mentioned on the side in the question, `otherProject` is a custom eslint-plugin, and the "main project" here is eslint plus plugins, for the eslint-extension in vscode. It's a setup to lint other projects contained in `main`. From what i found, eslint plugins are best added as a package (sadly the way eslint resolves them). I also thought about a proxy package, which just re-exports the plugin from its path. – Doofus Jan 17 '21 at 13:18