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.
Related
We had the following problem:
The project is install under /home/node/project
where project is a soft link to /home/node/deploy/project{version}
The package.json is under /home/node/
We did npm i in /home/node/project which should have found the package.json under /home/node/ and build the node_module has expected.
But for some unknown reason, about a month ago, someone created a package.json under /home/node/deploy
Therefor the npm i build a new node_module under /home/node/deploy which was defected
Although we suspected that the code is using the wrong node_module we couldn't figure out which node_module the code actually use and wasted long time until we realize that a defected node_module was created in the wrong directory
So I would like to know if there is a way to know which node_modules my project actually use at run time?
Delete one of the node_modules folders and run your code. If your code is running without any errors, then it may mean that it is using the other node_modules folder.
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.
I prefer to keep all generated files and dependencies outside my source tree while I work on it.
npm and grunt make that difficult: npm will never allow moving local node_modules, so I have to use --global and --prefix. But grunt does not support such a scheme, apparently.
How can I achieve my objective given the above constraints?
So, if I have a project:
foo/
.git/
src/
gruntfile.js
package.json
I want no extra files in my tree, specifically, node_modules. (Also bower_components and build etc but this is about npm.) This directory should remain untouched while I am working on it and running it. That is all.
Apparently npm link is supposed to do this, but when I tried it still installed all the dependencies in ./node_modules. Any other invocation I cannot fathom; the docs are not clear.
A related suggestion was to use another directory with symlink to my gruntfile or package.json, but grunt just resolved the symlink and continued to work in my original directory!
So far the closest I have come is to link to e.g. ~/.cache/foo/node_modules from my project. Although it achieves keeping the deps out of my tree, I still have this link cluttering my workspace.
I want to know if there is a better way. Will some combination of npm install, npm link, ln, ~/.cache, NODE_PATH and PWD allow me to run my project, from my source tree, and keep it clean of all non-source artefacts?
Swimming against standards is a Very Bad Idea ®.
What you can (and should) do is add node_modules/ to your .gitignore (or whatever ignore file you have for your given source control system) so you don't version these files.
Also, you can use a directory like src/ to organize your code and "shelter" it from the mandatory configuration files (package.json, Gruntfile.coffee, etc).
I have a project in which I use node-webkit. node-webkit allows npm packages to be used for developing desktop applications. I make use of grunt to build my application.
My folder structure looks like this at the moment:
project root
node_modules/ (1)
package.json (1)
App/
node_modules/ (2)
package.json (2)
bower.json
bower_components/
...
controllers/
filters/
...
app.js
The npm dependencies for the application itself are kept within the App folder, but the dev dependencies for building the project are not related to the application source code, so i keep them in node_modules (1) inside the root folder. I also know that in a package.json file one can express dependencies and dev dependencies, exactly for this reason. I would rather have one package.json file in the root expressing ALL dependencies, including dev dependencies, but i would rather have a separation of those dependencies on folder level.
Two questions arise:
Is this a good way to organize my npm dependencies? If yes, awesome? If no, which I expect:
What is a better way to organize my dependencies? Is it possible to specify that dev dependencies go into folder a, and 'regular' dependencies go into folder b? If so, how do I do this?
In case anyone is wondering, this is the project i am talking about:
https://github.com/michahell/pinbored-webkit
[updated folder structure to include app.js for clarity]
It is perfectly fine to keep more than one package.json file and multiple node_module directories for a project. If you consider the parts as separate components.
An example might be if, you have one directory containing a node server, another containing a react app, and a third containing some kind of deployment script written in javascript.
#Michael package.json file contains all the dependencies related to that project.There is no need for multiple package files and multiple node_modules folders..
But you need to check where is your App.js file!!
your App.js , package.json must be in same folder unless configured.
I'm developing a node project which depends on several npm modules. What I'm currently doing is committing all those modules to my git repository, pulling on my server, and then rebuilding the modules on the other end because the system architectures are different. What I would like to do instead, is just commit enough stuff so that npm knows what it needs to rebuild, and nothing more.
I would hoping I could do this without actually committing all the module files. I know little about npm's internals, but see that every module has a package.json file, is this all that npm will need? And if that's the case, how would I go about ignoring all files in my node_modules folder except the package.json files?
Thanks.
Why can't you just have a package.json file in your main application root listing all your dependencies? This file should then be the only thing checked in to source control.
At build time or when other developers pull the code, npm install should be run from the same directory that has your package.json file. It will then pull down all your dependencies locally.