I noticed there is a big discussion about what is the best build tool e.g. Grunt, Gulp, Webpack, etc. I first opted for Gulp, I read its documentation and started making my first gulpfile.js and it worked I started improving it with the time
But I also noticed that npm can be used as a build tool, I could do the same things I did with my gulp configuration using npm, it took me less time it was just command line instructions, no extra documentation to read.
These are my two configuration files. gulpfile.js and package.json
They do almost the same, basic tasks such as concatenation, minifications, transformation from JSX to javascript, etc, one using Gulp and the other using npm. My question is if are there tasks that I could not do with npm only? in the way that will force to use Gulp or another build tool.
Thanks in advance
Your question infers that npm scripts are less powerful or more constrictive than task runners like Gulp. They're not. With npm scripts you can:
Make direct command line calls
Reference npm packages in your npm script
Call separate JS scripts that leverage any npm packages you may need
Call shell scripts, Ruby scripts, Python scripts, and so on.
In short, there's nothing restrictive about npm scripts. So while no technology can do everything, npm scripts are capable of doing everything Gulp and Grunt can do. At their core, npm scripts, Gulp and Grunt are all just opinionated ways to run code.
Related
I'm a little confused as to why I can't get my Gruntfile.js to run, here's the rub:
I installed grunt globally using npm. It lives in my /usr/local/bin/ directory, here it is:
Previously, I'd installed node.js using homebrew, then grunt with npm. Other issues led me to uninstall node via homebrew & reinstall node directly from the disk image node provides.
In my web project's index, there's a Gruntfile.js script that rebuilds my jekyll site everytime live-reload updates. When I run grunt, I get this message:
What I'm trying to wrap my head around:
Why isn't /usr/local/bin/grunt a valid path? Grunt exists at that location. My guess was that running grunt locally, from within my website's index, would fix things.
There's a node_modules folder there & everything was working fine before after all. I found this link, and tried running \grunt to bypass the bash alias, but that had no effect.
Any advice/suggestions are much appreciated! I feel like an imbecile using things, breaking things & not understanding why/how. Eager to finish my project, get a paycheck & finally have time to learn the ins and outs of terminal, bash & popular package managers so I don't run into these sorts of problems...
After discussion with OP, I find this is a Node.js environment issue. After install - do something - uninstall - reinstall in another way - do something, somehow, when npm install -g XXX is executed, the symbolic link is created and point to some place, but the package is installed some where else. That's why OP see /usr/local/bin/grunt but cannot run it.
I've recommended OP to clean up all Node.js stuff, make a clean environment and start right from the beginning.
When installing anything via npm, it downloads dozens of not needed files. Usually I am looking for a library final build, a *.min.js file or anything like that but the rest is useless.
How do you handle all these useless files? Do you remove them by hand or generate the final app with any build tool like gulp or grunt?
I'm quite confused as I have plenty of npm modules installed in my webapp and the folder size is about 50 megabytes but it could be 2mb only.
npm install --production
Just doing an npm install brings in both development and runtime dependencies. You could also set the ENV to production globally for the server: npm config set production.
See this github issue. Note that this won't get you only the final minified build of everything, but will greatly reduce the bloat. For instance, a library might rely on babel-cli, babel-preset-es2015, and uglifyjs to be built (devDependency), but you don't need any of that if it also includes the transpiled minified file.
Managing Packages
For front end non-development packages I prefer Bower. It maintains the minified and non-minified version of your packages.
Build Tool
Use either Gulp or Grunt. Gulp would be my tool of choice.
Gulp task that will greatly improve your code are:
minification of both css and js
optimization/compression of images
concatenation and caching to reduce the number of calls to the server
package versioning
automatic injection of project dependencies
automatic injection of external dependencies
static analysis of js and css
automatic builds on code changes
deployment
testing
Node
If you can, leave to node all your development tools and leave to bower all your release plugins. Most node packages that are used in released apps have a bower installation counterpart.
Edit
Don't delete anything from Node manually as you don't know which packages have other packages as dependencies. If you are afraid that you may have junk in there, use npm rimraf to delete the node_modules folder, and then run npm install. Most importantly check your package.json for unnecessary saved packages.
Is it possible to define different locations in your NPM package for browser and for server (NodeJS)?
My code is largely isomorphic, but it is uglified and concatenated for browsers.
Short answer, is that you can't do such thing. Mostly your dependencies are stored under /node_modules folder.
You may override this option by running some patches or an installer script.
Here is a bug raised on Github about this issue.It's is also described in an official NPM blogpost
But don't feel disappointed, you may use Bower as a dependency injector for your client side code. I prefer it as it feels more semantically and separated:
Bower for the front end, NPM for the back end.
Moreover, NPM packages are built for CommonJs only, Bower packages instead are more plug and play solutions
I've been trying to get familiar with a few popular Javascript repositories on GitHub. It seems that I often pull down the repository, then run into an issue with some sort of dependency. Usually this will be something encountered during the npm install or the grunt run.
To be clear, these are not node packages that would be installed by npm, rather console dependencies that some grunt packages seem to need in place and to be available in the system's path variable.
I've had to install Git, Java, Bower, PhantomJS, and other packages after cloning new repositories and trying to build them. My question is this: Is there a standard set of console utilities (beyond just nodejs and those things that are installable via npm) that are expected for doing Javascript builds via Grunt?
I created a small test program for web applications that uses jasmine, and I'm preparing it for easy downloads. Before installing my package, the user's project should look something like this:
myProject/
app/
lib/
...
I want to be able to have the user cd to myProject in the terminal, issue a single command that points to the app and lib folders, and then end up with this:
myProject/
app/
lib/
requirejs
test/
lib/
node_modules/
specs/
SpecRunner.html
server.js
...
app/ should contain the js project files, lib/ should contain all the external js dependencies for the project, and test/lib/ should contain all the external dependencies for the tests. server.js runs with nodejs and depends on apps installed in node_modules/.
What's the best way to go about doing this? I could make a bash script, but I'd rather use a package manager. I'm not sure how I'd do this in bower or npm. And am I right in thinking it's better to have two libs, one for the project and one for testing, rather than one? I know I can declare certain packages as test packages in bower, but it seems like they should live in a separate libraries.
And am I right in thinking it's better to have two libs, one for the project and one for testing, rather than one?
No. The idiomatic way in the npm-verse is to have tests in the same package in the test folder. Since bower is based on npm I'd say the same applies there too. If you don't want bower users to have to download test-stuff you should be able to ignore the test folder in the bower.json file (according to this answer). You should also specify node modules that are only used for tests as devDependencies.
Developers who want to run your test should IMO install it directly from source using e.g. git clone git#github.com/your/repo.git (and then just run npm install). Or simply npm install x if it's available on npm. Even if you really want the tests in their own package, I'd still suggest not using a package manager but ask the developer to clone it from the repo into the test folder.
Anyway to answer the question, the following one-liner should work (assuming npm, I'm not too familiar with bower):
npm install x-test && mv node_modules/x-test test