3 ms·

I have question as someone that is still fairly new to node. The article recommends using npm for running tasks (for instance starting the application), but oth

by cmbaus 13y ago

I have question as someone that is still fairly new to node. The article recommends using npm for running tasks (for instance starting the application), but others recommend an external tool like grunt. Is it more idiomatic to use grunt or npm for these tasks?

buckbova 13y ago
I'm not a seasoned node hacker, but I've been using grunt tasks as provided by yeoman. http://yeoman.io/ http://yeoman.io/
bitcrusher 13y ago
Personally, I think using NPM is more idiomatic; Both Grunt and NPM are third-party tools, however NPM is FAR more pervasive with Node than grunt is. Essentially, if you write Node, you use NPM. Not so with grunt.
- cmbaus 13y ago
  To be honest, I didn't realize that npm could be used as a task runner, but now that I do, I'm wondering what all the fuss about Grunt is. Why bring in yet another meta-tool into the chain if npm (which is basically a requirement) can handle task execution already?
  - redidas 13y ago
    I'm not entirely sure about this, but it seemed like Grunt was more for front-end developers that haven't quite jumped into Node.js yet (or had no intention to). I've noticed some culture differences between front-end and back-end javascripters.
    - herokusaki 13y ago
      > I've noticed some culture differences between front-end and back-end javascripters. Could you elaborate on those?
    - akbar501 13y ago
      > it seemed like Grunt was more for front-end developers Grunt is a task runner. It's a general purpose utility, that happens to work well with JavaScript (client and server). Our team first started using Grunt to concat Scala templates prior to compilation (in an old version of Play with an old JVM). Back then, we noticed that concatenating the Scala files reduced the amount of heap used during compilation. Never did figure out why. Later, we started to use Grunt to minify and concat our Backbone code. Currently, we use Grunt for both our server-side Node and client-side Angular. Server-side we use Grunt to: 1.) Restart Node on file change, 2.) Run JSHint against both server-side and client-side JavaScript, 3.) Set some environment vars prior to starting Node, plus a few other small tasks. Client-side we use Grunt to: 1.) Create a production build by minifying and concatenating JS, 2.) Minifying and concatenating CSS, Minifying HTML, plus some other minor tasks. We also use Grunt to run the client and server test suite. Basically, it's common practice to use Grunt (or Gulp, or another task runner) to assist with both client and server-side JS.
2mur 13y ago
Here's the thoughts of substack on this issue. I use npm and bash scripts. http://substack.net/task_automation_with_npm_run http://substack.net/task_automation_with_npm_run
- cmbaus 13y ago
  "build": "npm run build-js && npm run build-css" Ok I see. That's sort of a poor man's dependency checker.
OWaz 13y ago
Another way to think about it is if you were to deliver the application to someone else. They shouldn't need Grunt to run your app. Providing an easy way to run the app with npm start is nice to have. Maybe add the npm install part to the process so they can just run one command to do two things. Going further you could set environment variables so production and development variables can be enabled easily. Just like you I'm still fairly new to the node way of doing things and just do whatever makes sense to me.
rev087 13y ago
I haven't used npm tasks yet, so take this with a grain of salt. Grunt has two main advantages: a rich plugin ecosystem, with easy-to-configure/use tasks for pretty much anything I can think of (preprocessing, concatenating, minifying, linting, live reloading etc.) and a standardized "language" to configure Grunt plugins (third party or your custom tasks). Once you familiarize yourself with the Grunt way of setting up tasks, it becomes trivially simple to obtain and run plugins for your tasks.
- sabhiram 13y ago
  Exactly! I actually have grunt tasks pointing to npm "scripts" to run. Here is a sample Gruntfile that does the following: 1. Runs unit tests any time source or test files change 2. Runs JsHint on the source any time it changes 3. Generates a static documentation site based on any edits I make to my markdown files 4. Brings up, tears down vagrant VMs which host a MongoDB (or whatever) instance This makes development workflow really awesome. Just do "grunt watch" in a terminal, and you will always be able to see your tests go from fail to pass as you develop your (linty clean) code. I have seen many others use (and mention the use of) Grunt to reboot the server on file change, this is one of those programing austerities I have not given up (yet). [1] - Sample Gruntfile - https://github.com/sabhiram/nodejs-scaffolding/blob/master/Gruntfile.js https://github.com/sabhiram/nodejs-scaffolding/blob/master/G... [2] - Grunt Plugins - http://gruntjs.com/plugins http://gruntjs.com/plugins

by cmbaus 13y ago

buckbova 13y ago

I'm not a seasoned node hacker, but I've been using grunt tasks as provided by yeoman. http://yeoman.io/ http://yeoman.io/

bitcrusher 13y ago

Personally, I think using NPM is more idiomatic; Both Grunt and NPM are third-party tools, however NPM is FAR more pervasive with Node than grunt is. Essentially, if you write Node, you use NPM. Not so with grunt.

cmbaus 13y ago
To be honest, I didn't realize that npm could be used as a task runner, but now that I do, I'm wondering what all the fuss about Grunt is. Why bring in yet another meta-tool into the chain if npm (which is basically a requirement) can handle task execution already?
- redidas 13y ago
  I'm not entirely sure about this, but it seemed like Grunt was more for front-end developers that haven't quite jumped into Node.js yet (or had no intention to). I've noticed some culture differences between front-end and back-end javascripters.
  - herokusaki 13y ago
    > I've noticed some culture differences between front-end and back-end javascripters. Could you elaborate on those?
  - akbar501 13y ago
    > it seemed like Grunt was more for front-end developers Grunt is a task runner. It's a general purpose utility, that happens to work well with JavaScript (client and server). Our team first started using Grunt to concat Scala templates prior to compilation (in an old version of Play with an old JVM). Back then, we noticed that concatenating the Scala files reduced the amount of heap used during compilation. Never did figure out why. Later, we started to use Grunt to minify and concat our Backbone code. Currently, we use Grunt for both our server-side Node and client-side Angular. Server-side we use Grunt to: 1.) Restart Node on file change, 2.) Run JSHint against both server-side and client-side JavaScript, 3.) Set some environment vars prior to starting Node, plus a few other small tasks. Client-side we use Grunt to: 1.) Create a production build by minifying and concatenating JS, 2.) Minifying and concatenating CSS, Minifying HTML, plus some other minor tasks. We also use Grunt to run the client and server test suite. Basically, it's common practice to use Grunt (or Gulp, or another task runner) to assist with both client and server-side JS.

2mur 13y ago

Here's the thoughts of substack on this issue. I use npm and bash scripts. http://substack.net/task_automation_with_npm_run http://substack.net/task_automation_with_npm_run

cmbaus 13y ago
"build": "npm run build-js && npm run build-css" Ok I see. That's sort of a poor man's dependency checker.

OWaz 13y ago

Another way to think about it is if you were to deliver the application to someone else. They shouldn't need Grunt to run your app. Providing an easy way to run the app with npm start is nice to have. Maybe add the npm install part to the process so they can just run one command to do two things. Going further you could set environment variables so production and development variables can be enabled easily. Just like you I'm still fairly new to the node way of doing things and just do whatever makes sense to me.

rev087 13y ago

I haven't used npm tasks yet, so take this with a grain of salt. Grunt has two main advantages: a rich plugin ecosystem, with easy-to-configure/use tasks for pretty much anything I can think of (preprocessing, concatenating, minifying, linting, live reloading etc.) and a standardized "language" to configure Grunt plugins (third party or your custom tasks). Once you familiarize yourself with the Grunt way of setting up tasks, it becomes trivially simple to obtain and run plugins for your tasks.

sabhiram 13y ago
Exactly! I actually have grunt tasks pointing to npm "scripts" to run. Here is a sample Gruntfile that does the following: 1. Runs unit tests any time source or test files change 2. Runs JsHint on the source any time it changes 3. Generates a static documentation site based on any edits I make to my markdown files 4. Brings up, tears down vagrant VMs which host a MongoDB (or whatever) instance This makes development workflow really awesome. Just do "grunt watch" in a terminal, and you will always be able to see your tests go from fail to pass as you develop your (linty clean) code. I have seen many others use (and mention the use of) Grunt to reboot the server on file change, this is one of those programing austerities I have not given up (yet). [1] - Sample Gruntfile - https://github.com/sabhiram/nodejs-scaffolding/blob/master/Gruntfile.js https://github.com/sabhiram/nodejs-scaffolding/blob/master/G... [2] - Grunt Plugins - http://gruntjs.com/plugins http://gruntjs.com/plugins