I just ran this line of code
npm install -g csslint
CSSlint seems great but I want to add the ability to prettify my css by putting in custom code. The goal is to have a command line interface where I can format my css before pushing the code to the server.
"-g" stand for installing globally correct?
Where does this library get installed to and how do I access it? I thought it would be in my user/local/bin but I couldn't find it.
Thanks!
use npm root -g to see where modules get installed. If you want to use it in your code using require() then install it locally i.e. without using -g option. More details here https://npmjs.org/doc/faq.html
I believe it's going to depend on your npm settings, but my global npm binaries are in /usr/local/share/npm/bin
Related
I have installed the tar-module using
npm install -g tar
When I type
npm list -g --depth=0
I can see the entry tar#6.1.0 in the module-tree, however when I try to require it in a js-file const tar = require("tar"), I get the error message
Uncaught Exception:
Error: Cannot find module 'tar'
What am I missing?
The issue here is that you're trying to use something installed globally in a local project. You should be able to use your libraries if you install them inside the project with npm i tar.
The reason we install something globally is for use during development on many projects. This way, we don't have to install a tool on every project. With something you want to use inside a projects code however, you should install it on a project level. This way everything that the project needs to work lives inside of the project itself. You should see all dependencies listed inside of your package.json file
Not gonna advocate you do this, but if you really want to include the globally installed library, you can do something like this:
require('./../../.npm-global/lib/node_modules/tar'); // Relative path to library
Where you go up the file directory to your $HOME directory into the default global install location for node and bring it in. This is poor practice, please don't do it, but heres the info none-the-less.
I've searched through other questions such as this one, but they all seem to be about a local npm link stopping working for another reason than mine. I assume this is a common use-case issue, so if I'm doing something methodically wrong, I'm more than happy to take suggestions on how I should be doing it.
Principally, I have a private npm module that I'm working on called #organisation/module. When working locally, I'll run npm link on it, and use it within my 'host' project as npm link #organisation/module — this all works great with hot-reloading, etc. I'll also import it as import module from '#organisation/module.
However, since I also want to publish my local changes to npm (as #organisation/module) from time to time, for build testing and production code, I need to run npm install #organisation/module on the host project.
This then seems to break the implicit npm link I set up earlier... I assume mainly because they are the same name, and npm favors an install over a link?
When I want to make live, local changes again, the only way I can currently get it to work is via npm uninstall #organisation/module and then to re-link it.
Is there a way to keep the published module installed (in order to avoid careless mistakes, like forgetting to reinstall it for build testing), but always favour the local, linked instance?
Diagram for ref:
Have you tried locally installing with the other method npm provides.
npm install /absolute/path/packageName
I believe this will change your entry in package.json to look like this:
"dependencies" {
...
"packageName": "file:../../path/to/packageName",
...
}
Since npm link creates a symlink in the global folder, while npm install is local to the project npm install takes precedence. You can read about npm link here: https://docs.npmjs.com/cli/link
To avoid this, my suggestion would be to use npm install <path to local> and when you need to use the production code use npm install #organization/module. This would update your node_modules per code basis. Read about npm install here: https://docs.npmjs.com/cli/install
Hope this helps :)
Go to the directory where your local package is located open package.json change the name from original_name to "original_name_local".
write npm link on terminal at the same location.
After this go to your working directory and write npm install <path to local>
Now whereever you're requiring or importing update the name to "original_name_local"
for example if it's require('space-cleaner') then change it to require('space-cleaner_local')
Like this you can have both local as well as production package just change the name wherever required.
Otherwise you can remove package by removing it from package.json and deleting from node_modules.
if local is needed go to local package directory and on terminal write npm link and then on your working directory write npm install ./path/to/package
if production then again delete the package as told above and write npm install package_name
What is the difference between these two installation methods for some npm packages?
This excerpt is from the installation section for pug:
Package
via npm:
$ npm install pug
Command Line
After installing the latest version of Node.js, install with:
$ npm install pug-cli -g
So these are my questions:
What are the advantages of using either of these two methods?
Why are these packages named differently (pug vs pug-cli)? I've noticed that some npm packages are suffixed with "-cli", command line interface.
npm install pug: This is basically used to install the node module pug within the dir you run this command from. Once installed it lets you use pug with the project.
npm install pug-cli -g: This is installing the pug's command line interface. The -g flag installs it globally which means, you could basically initiate pug-cli from anywhere.
Now, the CLI's in general provides a lot of methods on top of the underlying modules. These methods are not something you would need in your code, but more as convenience methods, like say starting a server, or for the case of pug, the CLI provides a methods to render all the templates in a particular directory.
As the part of your project: You would need Pug to write those those templates and convert them to HTML. But say you want to test a few templates, then you could use Pug-cli for that, instead of building up your code and then looking in the HTML's.
npm install pug: This is basically used in your current working project, it tells your node.js to render pug.
npm install pug-cli -g: using pug-cli gives you the power to be able to run your pug from the terminal, and including the pug-cli -g implies that your pug-cli will be installed globally which means you can run it from any CWD in your terminal.
Therefore all -cli (command line interface) modules have that ability of being ran directly from the terminal.
The Node.js npm (Node Package Manager) has a -g command line argument, which I often see referenced. For example, the documentation for the Microsoft Azure x-plat (cross-platform) CLI tool says to install it by using npm install -g azure-cli.
Question: What does the -g option do?
What options do I have to install node modules?
After writing this I quickly found and old but still applicable post by Isaac (yes, the npm #isaacs). But I still think the below post is informational.
You can install npm modules globally or locally - you already know that, but why?
Globally: npm install -g some-module-a: This module is intended to be used as an executable (i.e. CLI, file watcher, code minifier, logger, etc.).
Locally: npm install some-module-b: To be imported and used in your app via import, var someModule = require('some-module)
global modules are one of the best ideas of npm. We can easily create executables using node/javascript. If your node app is meant to be run as an executable, then you will want others to install it globally. If it's a utility, helper, application, etc. then you usually don't want it installed globally. So, unless the module explicitly states that you should install it with -g, then don't.
One more time: if you are wanting to use some module called some-module in your node app - var someModule = require('some-module'), then npm install some-module from the root of your node app to pull it into your local node_modules directory. If you've installed some-module globally and not locally, it will usually not load and will show you an error about not finding the module (even though it can be made to load the global module - hint: just don't!)
So what exactly happens when you install globally?
npm install -g [some module] installs the specified node module in a directory higher up in your file system (i.e. usually /usr/local/lib/node_modules in unix systems). The biggest use case for global modules is for CLIs written using node (think npm, bower, gulp, grunt, et. al.).
Let's look at what happens when you install bower globally:
*follow these steps in your command line/terminal
step: npm install -g bower
explanation: the module - all of it's files and dependencies - are saved in your global directory (e.g. /usr/local/lib/node_modules/bower).
Something else happened here. Somehow you can now run bower in your command line. Awesome!
step: bower -v --> results in the installed bower version (i.e. 1.6.5)
explanation: It's now a fully executable node app using bower as the keyword. Inside bower's package.json file you'll find a bin property:
"bin": {
"bower": "bin/bower"
}
So how did that all work?
npm will create a symlink from where most executables live, /usr/local/bin/bower over to /usr/local/lib/node_modules/bower/bin/bower, where the module lives. That symlink makes it so when the executable runs, it can reference other files in the original module, including it's local node_modules. Pretty cool, huh?
*Note on executables: If you create a file called awesomeness in /usr/local/bin/ and chmod u+x (user + executable) it. Then write some scripting in it (in this case javascript using #!/usr/bin/env node at the top). Then you can run it anywhere in your command line/terminal just by typing awesomeness.
Hope that helped. I know doing a deeper dive into it helped me early on.
Node.js packages can be installed one of two ways:
Globally
Locally
The -g option instructs npm to install the package globally. You would install a Node.js package globally, if you want to be able to call the command directly from the terminal.
From the documentation:
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 can 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.
To download packages globally, you simply use the command npm install -g , e.g.:
I have used to install my nodejs on D:\ drive instead of C and have set environment variables to D drive node & npm folders.
Then i changed npm installation path as "prefix=D:\node\node_modules\npm
" on "npmrc" file. So i could confirm that all user based modules are pointing on D drive npm folder instead of appdata.
I tried to install express js globally and i used to check the package tree on my cli as mentioned below,
npm ll -g
while trying this command am getting npm extraneous ERR,
Please suggest me that which way i have to use npm path and installation stuffs.
Thanks in advance.
It might seem like a good idea to install packages globally, but this is one great reason not to.
Often used packages like express, and cookies should be kept local to a package. Mostly because of versioning issues. You might have one package using express2, but your new one wants to use express3. You would have trouble if it was a global install. When in doubt leave off that -g, and use a --save instead. (This adds the package to your npm dependencies list.)
On the other hand, command line tools like mocha, yeoman, and uh not much else that I know of should be installed with the -g flag.
I'm not much of a windows person, so you'll have to look a little yourself, but I would also recommend not installing Node by hand, but instead using a version manager like nvm to do that stuff. Here's an nvm port for windows: https://github.com/coreybutler/nvm-windows