ok, so I didn't find my answer in the already asked questions. I recently had to reload my node to include trying to reload all the globally loaded 'things' (that I could remember).
Back when I was learning "Gulp", I remember having to do a separate install for gulp-util. But when I looked in the node > node_modules folder, I see where gulp-util was already loaded as a sub module of gulp. This was also a duplicated and exact version as to my separate install of gulp-util.
So does gulp (npm install -g gulp), now come with gulp-util as a part of its install process. So doing a separate install of gulp-util is pointless and overkill?? Or do I still need to do it???
Yes, you still need.
The fact that gulp-util is a submodule (along with any other) of gulp just means that gulp uses it, but doesn't mean that you don't need to include it.
If you want to get gulp-util from gulp you can do something like it:
var gutil = require('gulp/node_modules/gulp-util')
But, I strongly advise you not to.
Anyway, gulp is a build tool, overkill shouldn't be a concern here since you won't ship it or its rendundant submodules for the client.
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.
I'm getting closer to npm to manage the javascript of my project.
Looking at stackoverflow I saw this documentation: https://docs.npmjs.com/using-npm-packages-in-your-projects
but honestly I understood little and nothing...
I would like to install this package: npm install lightgallery lg-thumbnail lg-autoplay lg-video lg-fullscreen lg-pager lg-zoom lg-hash lg-share
running it he will put the package in node_modules.
always looking at the documentation I found: npm install <folder>, so I tried an told path to the directory at the end of npm install, but the install it inside the node_modules folder...
I'm using Laravel, and if I want to install something from npm to public/inc/plugins, which is the correct procedure? is it possible to indicate this in the packages.json file? If it is recommended to use the installation in the main node, how can I then use the js? with a reconstruction with webpack mix?
You shouldn't do that, because this is standard, and other developers may feel uncomfortable if you change this behavior.
In documentation, you can find:
Install the package in the directory as a symlink in the current project. Its dependencies will be installed before it’s linked. If folder 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.
Here you can find an answer on StackOverflow
I have recently just went in web-development and heard about these tools, I still confusing about it even I done research after, and also I have some questions as well. this is the following research I have done if there are something wrong please correct me.
Webpack is replacing bower and gulp
Bower was use to manage front end lib(eg: bootstrap), which gulp was use to manage backend lib(eg: backbone.js )
In some big project people still use gulp because give more control of the project
npm is the package manager for JavaScript.
If I want to I can install bootstrap from either npm or bower or gulp.
People choose to use bower and not just npm to install bootstrap is because npm does nested dependency tree, which Bower requires a flat dependency tree, which means faster.
Webpack replacing bower and gulp is because those are overkilling people's time.
The last thing is a question, I saw on youtube people download sass sass(which I understand is a front end thing tool)eg:(npm install gulp gulp-sass --save-dev) in gulp and then not using bower, is that even the the right way to do things? because if yes why do we still need to use use bower?
Webpack can be an alternative for gulp. Webpack doesn't do anything Bower does.
Bower was often used to manage frontend dependencies (eg, bootstrap), while npm was often used to manage backend dependencies (eg, express).
People use gulp because it's worked out for them so far, and the time/effort it takes to learn something else and switch to something else might not be worth it.
npm is a package manager for dependencies, but it isn't exclusive to JavaScript dependencies.
You can install bootstrap with Bower or npm.
Starting with version 3, npm installs everything in a flat hierarchy. You can use npm to manage dependencies that are used on the frontend AND backend, so some people don't see the point in having Bower.
Webpack can be an alternative to Gulp, but a lot of people had a hard time learning how to use Webpack.
Yes, you would npm install gulp-sass --save-dev, which installs gulp-sass with npm. I imagine gulp-sass is a tool that lets you use SASS and Gulp together. You wouldn't use Bower in any of this.
I just setup a test, and tried to npm install express even though express already exists globally on my system. To my surprise, instead of using the global version, it ended up re-installing a version locally!? Isn't it supposed to use the global version... Or am I suppose to use -g every time, even when I only want to use the existing global version. Otherwise, what's the point of installing anything locally!?
The answer is "NO". It isn't supposed to use your global version.
If you want to use your global version, then you doesn't need to execute npm install at all because it is already installed.
If you do it then, obviously, you are saying "I want to install it locally to my project". And more than that: "I want to install its latest version unless it is declared in my package.json with other explicitly specified version".
In fact, the actual question is: Why in the hell would you want to not install a dependency of your project locally? To have more version mismatch issues?
As #anshuman_singh says, best practice is to always do an npm install --save.
You are able to use globally installed packages, of course. It could be handy for fast testing code that you will drop just after a few hours or so.
But, anyway: If you doesn't have really hard disk or network bandwidth issues, installing all dependencies locally will avoid you too much trouble in the future.
On the other hand, uploading that modules to your code repository is also a bad idea (maybe that is what you were trying to avoid) because, with different versions of node, most native modules won't work if not rebuild. But most VCS support ignoring files and or directories that must not be uploaded.
For example, in git (.gitignore file):
**/node_modules
In summary:
npm init (if you didn't already it).
npm install --save for all your project dependencies.
npm install --save-dev for dependencies not needed in production (testing stuff).
Don't upload node_modules to your VCS.
After new checkout: npm install or npm install --production (to not install dev-dependencies).
npm install -g only for tools you will use in console.
This way, you are sure that you will have in production (or other dev environments) the exact same version of each package.
And, finally, if you ever want to upgrade some package to its latest version, simply run:
npm install --save <pagkage_name>#latest.
If you’re installing something that you want to use in your program, using require('whatever'), then install it locally, at the root of your project.
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.
The first option is the best in my opinion. Simple, clear, explicit. The second is really handy if you are going to re-use the same library in a bunch of different projects
Install locally-
npm install moduleName
install locally and save in package.json-
npm install moduleName --save
install globally-
npm install moduleName -g
According to Heroku I should avoid global dependencies when asking Heroku to build my project. But I still want Bower and Grunt on the command line.
My question is: how then should I be running these tools?
Rather than installing them with npm install -g, should I be adding paths from node_modules to PATH, or the like? (Ubuntu)
If Grunt/Bower are installed globally on development machines -say when someone new starts on the project -then presumably npm install -g grunt-cli might give a different Grunt version to what's in package.json. Hence what Heroku runs and what developers run might accidentally differ.
(Or is that unlikely to be a problem?)
The best practice is to keep everything local, with npm install --save.
That way you can align versions for everyone in the team simply by tweaking the package.json file.
If you only need Bower and Grunt etc. to be available in your dev environments, then install them with npm install --save-dev. This will cause them to be saved in a devDependencies section in your package.json. Dependencies referenced therein will not get distributed to production (e.g. Heroku), but will be available in all your dev environments.
If you really do need Bower and Grunt etc. to be available on Heroku, then install them with npm install --save.
At any rate, npm should automatically save symbolic links to your executables (e.g. grunt-cli) in directory node_modules/.bin, and should take care of adding node_modules/.bin to your PATH, so you don't have to worry about that.