Just found out that yarn does not install same modules again and again in different projects and so you can recover some space from the hard drive, so my question...Is there a way to transfer or migrate npm modules installed globally to yarn and what exactly should be done, in every single project, which previously got it's dependancies through npm?
Related
I would like to create a new npm project with a few modules on a machine without internet access.
This machine has various older projects each with a node_modules folder with lots of modules in there.
Can I somehow tell npm to use all these modules to create the new project instead of going out to the internet?
When I just issue
$ npm install browser-sync gulp gulp-sass
npm obviously tries to download these modules from the internet instead of gathering them from the various node_modules directories on the machine where the modules already exist!
Note: Do guide me if something is missing.
So, I wanted to install a package from https://rnfirebase.io/auth/usage, but I have an npm project. The command on the website has only for yarn. I don't want to add yarn to project because (Is there any harm in using NPM and Yarn in the same project?) it states that it is not recommended.
So, then how do I install it with npm?
You have to use yarn, or you can look for a package that has the functions that you are looking for using npm
You can install it with npm just fine, don't worry. They are all package managers installing npm packages from the same repository. There is no difference in what you are installing or how they are installed. You can get different node_module structures, but for yarn you need config for that.
Yes its not recommended because it generates different lockfiles that will dictate different structures and versions in your node_modules folder. You want multiples devs to have the same "experience". However, lots of JS frameworks will come pre-configured with yarn, like React Native and you just end up having two lockfiles. One for npm and one for yarn. There is no harm in deleting the yarn file and keeping the package-lock. If you delete both, a new lockfile for the package manager you are using will be generated on npm i | yarn i | pnpm anyway.
To install it with npm just use npm i <PACKAGE_NAME> so npm i #react-native-firebase/app.
Here is the npm repo page for that package, https://www.npmjs.com/package/#react-native-firebase/app, notice the install command is npm! Only reason firebase devs only mention yarn is because they are hipsters ;)
I know pnpm and yarn reuse modules that we already installed, what, in not updated tutorials that i see, we see that this is something that pnpm and yarn came to fix in npm, which downloaded the modules from the internet every time we install it. This still a thing? Does modern npm save cache or something to speed up installation?
Yes, npm has a cache of package tarballs. It does not download the packages from the internet all the time. In fact, you can verify that by running npm install --offline.
The reason npm is slower than pnpm is because of other reasons:
pnpm uses a content-addressable store. Each file inside the node_modules directory is a hard link to the content-addressable store. This makes pnpm faster and more disk space-efficient.
also, pnpm is running the installation stages separately for every installed package. npm cannot do all these operations concurrently as of the current latest versions (v6 and v7).
There might be other reasons pnpm is faster but these 2 must be the most important ones. npm's cache is not one of the reasons.
I am having difficulties trying to install a development branch of React-Admin packages with NPM in an active project, specifically:
ra-tree-ui-materialui
ra-tree-core
To have the changes made in this PR https://github.com/marmelab/react-admin/pull/3379
Is there any way of doing this in a similar way to how you normally would put this in package.json ("username/repo#branch")
It is difficult to install a local version of one of React Admin's package, because we use a mono-repository that contains all the packages.
I see two solutions to your needs.
Install the alpha builds
The core team had just published an alpha for the next version of React Admin. It's not stable yet, but you can try it by running :
npm install --save ra-tree-core#next
npm install --save ra-tree-ui-materialui#next
Install a local version for development
If you want to tweak the React Admin packages while you are using them, you can fork the whole repo and use symbolic links.
# On a separate folder
git clone git#github.com:marmelab/react-admin.git
cd react-admin
make install
make build
cd packages/ra-tree-core
npm link # This will make this package available for linking
And on your project, then run:
npm link ra-tree-core
This will create a symbolic link between your local ra-tree-core and your node_module folder.
I showed these examples with npm, but yarn link works too.
When I deploy my app to AWS, it's copied into a new directory, so NPM will install all the same packages, during each deploy, which can take a lot of time. Most of these packages haven't changed between builds (if at all), so having it do a full npm-install seems like a waste.
My app server runs a bunch of different Node apps, so installing globally isn't an option. Instead I'd like to have the app store it's node packages in a location that isn't wiped out during deployment, but have the option to update packages as necessary during npm install.
Does NPM have a concept of an app-specific module directory that isn't located in a subfolder of an app? That way I can delete the app folder, and not have to reinstall the same packages over and over again.
I could achieve this by using symlinks, or migrating the current node_module directory.
If you lock down your dependencies versions, NPM is likely to cache the packages. So the installation wouldn't take much longer.
If you prefer not to do this, you can install dependencies globally and link them with the npm link command (which is basically creating a symlink yourself!). Then, it'll be up to you update the globally installed packages regularly.