I forked a package and made some changes and need to install it locally. Here's my branch.
I ran:
yarn add 'saber2#https://github.com/ilmoi/saber-common#head=ilmoi_support_v0'
which successfully installs the package, but it's missing both /src and /dist and so it unusable.
Having searched for similar issues I unsuccessfully tried:
building and commiting /dist dir (made sure not in .gitignore)
adding a "files" line to package.json (both top level and inside the workspace)
adding a "prepare" line
adding a blank .npmignore
None of those works. Here's how the package looks in node modules:
I suspect the problem is to do with workspaces. For some reason none of them compile / show. Please advise on what I'm missing.
I am a dev on a team inside a very large project. This is the first time I have worked on a project where the node_modules/package-lock files are not in the root of the project. I am used to personal projects with a few folders, files, and the node_modules/package-lock in the root so I can always easily "npm install..." in the root.
I am running into an issue when I try to run npm install (package), it completely breaks my local project. I have to rollback the changes, rebuild, and it works fine again.
Things I have tried:
Navigate to the same directory that node modules is in.
Example: C:\Users\USERID\source\repos\companyName\companyName2\Web\Administration.
Node_modules and package-lock are located here along with ~20 other various folders.
Navigate to the root (even though node_modules isn't located here, figured I'd try).
Navigate to one folder above. I tried this because this is the directory where the Visual Studio .sln file is located.
Example: C:\Users\USERID\source\repos\companyName\companyName2\Web\companyName.Web.Administration.sln
For more context, the specific file I need to add a package to is: C:\Users\USERID\source\repos\companyName\companyName2\Web\Administration\ClientApp\app\letter\letter-create-main.component.ts
I am hoping I can get some clarity on how to properly run npm install in large projects so I can add packages that I need to this monster of a project, and hopefully help others that have this question at the same time!
I have a project using VueJS, Webpack and some JS Plugins, like Jquery Datatable.
Everything goes well, i have a package.json where has all depedences. Here we a team with 10 developers. Not all of them work with this project, there are some developers that touch in this project every month. They already have all project, nothing changes with package.json dependences, but when i build the project, there are some strange errors in terminal, like not found some dependences(?) even all folders being there. Nothing changed with node_modules folder. If i delete it and run npm install, it works. The question is: "Why does the folder node_modules "lose" the references when it is a long time without moving the object?"
Thanks!
On the production server node_modules folder is a symbolic link for continuous deployment purposes.
When I run gulp command, I got many errors like this:
Error: Unable to find a browserify-shim config section in the package.json for /home/web/www/persist/node_modules/jquery-ui/jquery-ui.js while parsing file: /home/web/www/persist/node_modules/jquery-ui/jquery-ui.js]
filename: '/home/web/www/persist/node_modules/jquery-ui/jquery-ui.js'
. . .
If I move node_modules in project folder, build process is successfull. How to solve this problem?
Answer from thlorenz (author of browserify-shim)
Linking breaks browserify and shim since your projects dependencies
are outside of your project tree. So when looking upwards these tools
can't find the package.json of your package anymore.
So don't link your node_modules folders .. it's a bad idea anyways
since you're then linked to a global in your system, i.e. it's better
to have all your deps be local to your project. Not sure what your
deployment purposes are, but to me it seems like whoever made that
decision didn't fully understand how node/npm is supposed to work.
Recently started working with Gulp and I can't figure out is it really necessary to have a copy of node_modules directly in folder with current project?
E.g. I have this structure:
mysite
└─builder
└──node_modules
└─work
└─work2
How can I access node_modules in folder 'builder' from folder 'work' or 'work2' without copying it? It is quite large, about 100mb, and seems to me it has no sense to have a copy of it for every new project.
I tried this line export NODE_PATH='D:\OpenServer\domains\mysite\build' in file package.json and then tried command gulp but it replied[10:24:27] Local gulp not found in d:\OpenServer\domains\mysite\work
[10:24:27] Try running: npm install gulp
Short answer
Don't do it. Let NPM work the way it's designed to. However, to save space, you can delete the node_modules folder on projects that are currently dormant, and recreate it with a single shot of npm install when you switch back to them.
Justification
Even if you share your node_modules, you'll probably have redundancies in it anyway. What will you do about them next ?
It is the essence of NPM to replicate modules per project. If you dig into the node_modules folder tree, you may notice that it can even contain several replications of a same library under one given dependencies tree. Say you requested two modules explicitely, and both these modules themselves pulled a dependency that takes care of a lot of things, and is therefore called lib_DADDYMUMMY :
node_modules
+ a_module_you_use v0.5
+ lib_DADDYMUMMY v0.1 (pulled as a dependency of this module)
+ another_module_that_you_requested v0.3
+ lib_DADDYMUMMY v0.1 (again ! pulled as a dependency of this other module)
This comes in handy when your two module start needing different versions of lib_DADDYMUMMY. This comes in handy when you maintain long-lived projects ! And hell knows that in the JavaScript world, with fast changing APIs, you can consider most any decent project as long-lived. :)
One could imagine having all dependencies being shared by everyone, living in a flat structure, with several versions of a library living next to each other and every one finding what he needs there. That repository could be called, say, .m2. But that's just not the way NPM works unfortunately.
NPM considers that storage space is cheap. That's its price for helping you manage versions in dependencies, dependencies of dependencies, and dependencies of dependencies of dependencies. I consider that it's an affordable price for taking care of the dirty jobs the day when work and work2, as their lives go on, take diverging maintenance paths. I wouldn't try getting in its way by forcing a half-Maven-like folder model.
Maybe you should put your package.json into your root directory(mysite/package.json),
then try to install node_modules on the root.
In addition, you write gulpfile on the same dir.
eg.
mysite
|- package.json
|- node_modules
|- gulpfile.js
└─builder
└─work
└─work2
However, I recommend that you write one single gulpfile for each project.
One problem why you shouldn't do this is because of versioning. If your modules require different versions of the same package, you're going to run into problems. One package is going to win, and it might break another package.
Further, you get into the problem of having to merge the dependency lists in some way - meaning, you'll have to get the dependencies from work/package.json, work2/package.json, etc. and then install all of them at once.
Merging node_modules/ won't solve your problem, either - believe me, don't try.
Paste the node_modules folder inside your mySite directory.
All npm packages such as gulp will work in your work or work2 directory.
But, now(your folder structure) work folders can't find node_modules in their parent directory.