I am new to node, i have made few small application using node, but everytime i have to use npm install for every application which download the required dependencies in node_modules folder. There are many libraries which are common.
I tried installing using npm install express -g but i was not sure how to use this dependency in other application which is in some other folder.
Is there any way i can have only one folder like in D:\Users\User\AppData\Roaming\npm\node_modules from where my all applications can have the module which they need ?
Can anyone let me know how to do the settings for the same ?
Any help would be highly appreciated !!
Every node application that has a package.json has a specific set of rules for using specific versions of it's modules. You can install globally only one version of a specific module, but if you happen to have an application that needs an older / newer version that is not installed globally on your dev environment, then it will fail to work.
The recommended way of using node modules ( packages ) is to have a local directory inside your project, which contains all libraries that the project needs. This practice is everywhere and so you should follow it.
There are some ways to mitigate the slow npm install, though.
There is a new npm-replacement, created and maintained by Facebook, called yarn.
What yarn does is it creates a local cache of all installed packages and then symlinks them to your project folder from your local computer cache. This way the npm install procedure becomes very fast.
Related
I've been working on a lot of different node.js projects. All of them have their own package.json file with their own needed packages. Every time I run node <mainfile>.js, npm installs all the packages to the project directory. Like so: C:/Users/me/Projects/<project-name>/node_modules.
This isn't a very big problem, but is there a way to make npm use/install to the global packages? Like in C:/Users/me/node_modules?
One of the advantages I could see this having is less storage being taken up, although it isn't a huge advantage.
I would assume that if it is possible, it would require you to add/modify something in the package.json file.
While looking into answers for this question, I've seen people saying that you should avoid installing packages globally. Can you also explain why this is a bad practice andy why I should avoid it?
Install Package Globally
NPM installs global packages into //local/lib/node_modules folder.
Apply -g in the install command to install package globally.
npm install -g express
To answer your other question
The obvious short answer is that your project depends on them. If your
project depends on a package, it should be documented in package.json
so that you can guarantee that it is installed when someone types npm
install. Otherwise, you’ll need to add extra steps in your README file
to inform anyone else who clones your project that they need to
install each of your global dependencies as well
Finally, even if someone installs the correct version of Browserify
for your project, they may be working on a different project that
requires a different version of that same tool, which would cause
conflicts. Several of your own projects might even use different
versions of Browserify because you updated it when you started a new
project and didn’t go back to make sure that earlier projects were
updated to work with the new version. These conflicts can be avoided.
You can only have one version installed globally. This causes problems if you have different projects that rely on different versions of a package.
Why not to install all packages globally
It's not really you shouldn't install a package globally it's more knowing what packages to install globally. The packages to install globally are ones that your project/application does not depend on.
How to identify a package that my project depends on
A package that your project is depended on is a package that your application could not run without like axios or express (an express API could not run without express installed or a web page that makes API requests with axios cant make those requests without axios) but something like http-server or minify is not needed to run the application so it can be installed globally.
Why is it important to have locally installed packages
It's important/good practice because if you are working with a group of developers or someone gets your work from Github they can just run npm install and get all the packages with out having to find all the packages them selfs.
How can I remove the node modules folder
You could technically globally install every package but I would sudjest not to. Node and many other developers know this is an issue that they have created a solution for in deno "the node killer".
I would recommend not installing all packages globally and if the node modules folder really annoys you try deno it fixes a lot of things that node developers hate.
From what I have read it is a good idea to use the same version of Node.js throughout the development and production phases of an app.
Is this also true of NPM? It looks as if NVM is keeping specific versions of NPM together with specific versions of Node.js inside the .nvm directory. However, although I can see from the NVM documentation how to make sure you run an app with a particular version of Node.js, I can not see how to make sure that a particular version of NPM is used for a particular app. For example if I run the command npm install package from the root directory of an app I think it will use the default version of NPM not the specific version associated with the Node.js version specified in the .nvmrc file of the app.
Do I need to be consistent in the version of NPM I use during app development and production? If the answer is yes how do I achieve that?
When we start a Project using Nodejs a file named package.json is created automatically and it keeps track of all the dependencies in the ongoing Project. So you do not need to worry about the versions, you just have to start the project and all the dependencies will be taken care of.
Suppose you need to share your codes(like Git) then you just need to share your codes and package.json file that will do the trick.
We're developing an Electron app with a dependency upon an SDK (that we're also developing). Typically, once the SDK is ready, we do a new release and update the Electron app to use it.
But I'd like to make a local change to the SDK and have the Electron app consume it. This is proving problematic.
The approach I took is to, from the Electron app directory, run
npm install /path/to/sdk/moduleB
i.e. Based on the answers to how to specify local modules as npm package dependencies
However there's a problem. The SDK's sub-modules registers with a core module. i.e. To make an instance available.
When I use a local path to moduleB it cannot find the core module. I don't specify core as a dependency in moduleB. But if I do npm installs a copy under
/path/to/sdk/moduleB/node_modules/core
rather than re-use the module already defined at
./node_modules/core
i.e. Even though they're using the same version.
This behaviour (at least the re-installation of core) makes some sense if you understand how npm resolves the same dependency with different versions.
https://medium.com/learnwithrahul/understanding-npm-dependency-resolution-84a24180901b
and
https://docs.npmjs.com/cli/install
npm install :
Install the package in the directory as a symlink in the current project. Its dependencies will be installed before it’s linked. If sits inside the root of your project, its dependencies may be hoisted to the toplevel node_modules as they would for other types of dependencies.
But it seems the install creates a symlink and npm can't search back up into
./node_modules/core
The only way I've been able to work around this is by copying
/path/to/sdk/moduleB
to
./node_modules/moduleB
Is there a better solution that'll allow me to re-use the
./node_modules/core
dependency?
is there any way to route npm install to a specific part of hard drive and when i do npm install it make node_module folder in that part of drive, and when i run any project it look for dependencies in that part of drive,
just like single pool for every project.
then if i have two projects with similar dependencies then i only need to npm install in one project so dependencies become available in pool, and no need to do npm install in another project just npm start
Thank you,
Inzamam Malik
You can achieve something close to what you are describing with the link option.
From https://docs.npmjs.com/misc/config#link:
If true, then local installs will link if there is a suitable globally installed package.
Note that this means that local installs can cause things to be installed into the global space at the same time. The link is only done if one of the two conditions are met:
The package is not already installed globally, or
the globally installed version is identical to the version that is being installed locally.
So you will still have some files in each project's node_modules, but you shouldn't have as large a folder.
To turn this behavior on, run:
npm config set link -g
Edit: There is no way you can avoid running npm install and having a node_modules folder. Node.js always looks in node_modules for dependencies (this behavior pre-dates npm itself). The link option will make npm create symlinks in node_modules, pointing to a common pool. That will reduce disc usage, but you cannot do away with node_modules.
You can use PNPM Package manager, It uses a global pool for dependencies.
I'm quite new to ReactNative so sorry if it's obvious, but..
Each RN project init-ed via CLI has a large number of node modules stored in project_root/node_modules. Not that I would mind, but if you have several projects it seems redundant and takes up time/space to move it to the source versioning system.
Wouldn't it be possible to retrieve all these same modules from the general node_modules on the machine instead ?
You never want to store dependencies nested in node_modules in your source control... it defeats the whole purpose of versioning and dependencies in general. Your package.json file will specify the versions so when you run npm install it knows exactly which dependencies to grab.
As an alternative, Yarn is an up and rising package client that Facebook developed that does a much better job of caching your packages locally so that way if multiple projects reuse the same depencencies, it will still satisfy the need to keep them in node_modules but doesn't need to perform http requests for each one.
Yarn doesn't replace NPM as a package registry, just a better client to download, maintain, and cache those packages.
Yarn also adds a yarn.lock file (similar to Ruby's Gemfile.lock) that allows you to lock in the specific versions used in your app, regardles of the package.json. This file can be stored in version control, which is probably what you were wanting to achieve by saving the node_modules in version control.
Some good reads...
Yarn vs NPM
Scotch.io Yarn Tutorial
Why I'm working on Yarn (Yehuda Katz)
I would echo Brad's answer: Don't put node_modules in version control. npm install will install the correct versions from the package.json. Just put package.json in version control, not node_modules.
However, if you still want to save disk space, you can install some of your dependencies in a general node_modules folder by using the link option:
npm config set link true -g
You can read more about link here: https://docs.npmjs.com/misc/config#link.
Note that you must not include node_modules in your version control when using this option since npm will put symlinks to the globally installed packages in node_modules. The global install location varies from machine to machine, so if node_modules is in version control, it may link to non-existent locations.