Does it matter whether you install a global package with yarn global add PACKAGE vs npm install -g PACKAGE ?
Is there any difference at all, like where files are installed?
If yes, what is it?
So yes, you are right it is different. For npm it is something like below
/Users/tarunlalwani/.nvm/versions/node/v9.2.0/lib if you are using nvm
You can get this path using
$ npm config get prefix
/Users/tarunlalwani/.nvm/versions/node/v9.2.0
Where does npm install packages?
While yarn uses other paths
Windows: %LOCALAPPDATA%/Yarn/config/global
OSX and Linux non-root: ~/.config/yarn/global
Linux if logged in as root: /usr/local/share/.config/yarn/global
How to display yarn globally installed packages?
See this thread as well
https://github.com/yarnpkg/yarn/issues/2049
This is the document about Yarn global
yarn global is a prefix used for a number of commands like add, bin,
list and remove. They behave identically to their normal versions
except that they use a global directory to store packages. The global
command makes executables available to use on your operating system
and this is the document about npm install global mode
In global mode (ie, with -g or --global appended to the command), it
installs the current package context (ie, the current working
directory) as a global package.
I think there is no difference between them. Install a package as a global useful for developer tooling that is not part of any individual project but instead is used for local commands
Related
What is the equivalent command for npm ci in pnpm?
According to the documentation for npm install:
pnpm install is used to install all dependencies for a project.
In a CI environment, installation fails if a lockfile is present but needs an update.
How is the "CI environment" defined?
What does the following mean? Dependencies could be updated, but the
pnpm-lock.yaml is not touched?
pnpm i --frozen-lockfile # pnpm-lock.yaml is not updated
What is the equivalent command for npm ci in pnpm?
The equivalent is
pnpm install --frozen-lockfile
However, even if you don't use --frozen-lockfile, pnpm will automatically use a faster installation strategy if the lockfile is up-to-date. This is controlled by the prefer-frozen-lockfile setting which is true by default.
How is the "CI environment" defined?
pnpm uses the is-ci package to detect whether the environment is a CI.
pnpm i --frozen-lockfile # pnpm-lock.yaml is not updated
It means that if the lockfile is not up-to-date with the package.json file then pnpm install will throw an exception instead of updating the lockfile. If the lockfile is up-to-date, pnpm will do any necessary updates to the node_modules.
It's an old question, but I found me in the same problem.
Hope to help someone with this.
In Unix-like environments (e.g. Linux), use
CI=true pnpm i
You can even set in the package.json a script called ci with this command, what will make pnpm ci work as expected.
In other environments, the idea is the same. Set the CI env variable to something truthy.
Explanation
I'd investigate this question based on Zoltan Kochan's answer:
I found that PNPM changed from using is-ci in favor of ci-info (from the same developer, and is-ci itself uses ci-info).
In fact PNPM uses this to determine if it's a CI environment
ci-info checks for several cloud vendors, but it follows the CI environment variable if it is set
I have tested this, and you can view or clone the code from: https://gist.github.com/40b75f11125cd9986611ec6b9b97b8b4.git
I've also opened an issue in the GitHub suggesting this command as a new feature.
When developing with Angular, one can
npm install
to install packages locally, or
npm install -g
to install them globally. I am wondering what are the implications of each practice. And what happens if a particular package is installed both ways, perhaps with different versions? Which one will my Angular app use?
From there https://www.quora.com/When-do-I-install-a-package-locally-or-globally-in-NPM
In general, the rule of thumb is:
1. If you’re installing something that you want to use in your program, using
import { 'whatever'}, then install it locally, at the root of your project.
2. If you’re installing something that you want to use in your shell, on the command line or something, install it globally, so that its binaries end up in your PATH environment variable.
I'm trying to install Gulp for my Angular UI project and I'm a bit surprised by the fact that it won't install due to it's dependencies. So, node installed fine, but npm.js refuses to install due to file path too long error. My folder structure is 75 characters long, of the 260 available characters, that leaves 185 characters for npm to use. Am I missing something here, or do the npm authors expect me to fire up a linux box for my UI? (A deal breaker)
Update:
What is the best way to install gulp as a dependency for my Angular UI project? (My goal is to ultimately have gulp become part of my TFS CI)
Ignoring your path length problem for now (you may want to split your question), as far as how to get gulp installed, you just need to include it in your package.json file as a dependency.
You can do that by running npm install --save gulp
However, that does need npm installed first.
The easiest way to do this is to download and install Node from:
https://nodejs.org/en/download/
This will install Node and npm globally, which should avoid your path length problem and in my experience is the standard approach (I've not worked with TFS, but all other CI pipelines I've worked with support Node via a container image or build option/step).
If you dont want to manually install Node, you can use something like Chocolatey to install it automatically (you can install Chocolatey from https://chocolatey.org/ and then you can run choco install nodejs from your command line).
I have a jenkins build that is failing with the following error:
+ npm install
npm WARN prefer global coffee-script#1.12.4 should be installed with -g
Curious as to why coffee-script, or any package for that matter, needs to be installed globally?
Because coffeescript is a command line tool which can transpile coffeescript into javascript, or run as as an interactive shell similar to node.
from the NPMJS docs:
There are two ways to install npm packages: locally or globally. You choose which kind of installation to use based on how you want to use the package.
If you want to use it as a command line tool, something like the grunt CLI, then you want to install it globally. On the other hand, if you want to depend on the package from your own module using something like Node's require, then you want to install locally.
It would technically be possible to install these CLI packages locally, but then you would have to run them using a relative path such as(untested):
./node_modules/coffeescript/bin/coffeescript
I have just installed Homebrew and then I have installed Node (via $ brew install node). When node was installed, npm was automatically installed too (why?).
anyway, now when I install any package from npm, for example $ npm install -g express - it is installed in two locations:
Users/myuser/.npm/express and usr/local/lib/node_modules/express
$ which express retrieves me usr/local/bin/express which refers to usr/local/lib/node_modules/express. I think it's ok that it's installed inside usr/local/lib/node_modules/.. because I used -g flag; but why it is also installed under my own user (Users/myuser/.npm)?
In addition, how does the terminal know about express command? I didn't define any .bash_profile file. how does it know to go to usr/local/bin/$PATH?
Node installs NPM also because Node without NPM wouldn't be Node! :)
NPM is all about a succesful registry. You wouldn't go much further without it.
~/.npm is a cache for all packages - so this actually isn't an installation. As you may know about caches, this is just to avoid re-downloading things over time.
Also, this is configurable via the cache config.
Finally, the last location - usr/local/lib/node_modules is the actual global installation of Express.