19

So I've been reading about Gulp and Grunt, and how they can minify code, compress files, combine files into one, livereload etc. However, Meteor does all that already, with Isobuild.

The reason I'm asking is someone suggested using Gulp with Meteor, and I don't see a need for it. What are some possible reasons why I should run Gulp alongside Meteor? Or it is simply redundant?

If it is not redundant, what features does Gulp has that is not in Isobuild? And will the Meteor team plan to incorporate Gulp into its next versions?

dayuloli
  • 16,205
  • 16
  • 71
  • 126
  • 3
    Nope, Meteor has its own [build system called Isobuild](https://www.meteor.com/isobuild). Like you said, this automatically handles watching your files, compiling them, concatenating and minifying them, and sending them down to the browser or into the server for hot code pushes. It even live-injects CSS changes into the running application. Meteor packages can also hook into Isobuild, such as registering new filetype handlers. – sbking Dec 20 '14 at 12:15
  • @sbking Thank you for the link, I wasn't (even though I should be) aware of Isobuild. Would it be correct to think of Isobuild as more focused on allowing the **same** build process for the user regardless of platform, over having the focus on simplifying the build process? If so, are there still things Gulp can do that Isobuild cannot do? – dayuloli Dec 20 '14 at 12:20
  • 2
    Gulp allows you more control over the specifics of your build process. Isobuild automates the build process in an opinionated way specifically for Meteor applications and packages, which makes it extremely easy to write isomorphic code that can be packaged for various environments. I wouldn't bother complicating the build process, unless you can think of some specific task that you need Gulp for that can't be handled with an Isobuild plugin. I can't personally think of a reason to use Gulp with Meteor. – sbking Dec 20 '14 at 13:29
  • @sbking Thank you for your time and explanation. I'll just use Isobuild for now and learn Gulp for when I write Node.js without Meteor! Thank you! – dayuloli Dec 20 '14 at 13:32
  • I also don't see a reason for gulp or grunt in a typical Meteor app. Most of the common things are already covered by packages and built-in functionality: minification, coffeescript compilation, etc. But I would be interested to see when isobuild is not enough. – imslavko Dec 20 '14 at 19:44
  • `isobuild` link no longer works. :( – PythonNut May 26 '16 at 16:05

1 Answers1

31

Need is probably not the right word. Whether you want it or not is a different story.

As the comments mentioned above, Meteor include a very clever build system of its own called isobuild, which builds your WHOLE application for you. But there are certainly instances where you may want your own tasks which would best be accomplished through grunt or gulp. (The range of tasks you can accomplish with these is staggering, so I'm only going to list a couple simple common examples.)

The most obvious is going to be for assets you want to put in your public folder. But this is far from an exhaustive list of tasks that you may want to automate on a larger project.

  • Compile SASS files not using the libsass compiler (because it doesn't support all the features)
  • Compress and optimize images, svg files, favicons, etc.
  • Create multiple sizes / versions of images
  • Create Sprite Sheets
  • Concatenate and minify scripts in your own order / manner
  • Combine with Bower to manage front end packages that aren't available through atmosphere etc.

The way I would approach it is by putting all of this into the private folder, so its avoided by the meteor isobuild build system.

I believe these are enough reasons to not consider Gulp or Grunt redundant, and the range of tasks possible with grunt or gulp are so varied they can't all be listed here. Needless to say IsoBuild is fantastic for what it does, but would not replace everything possible with these task runners, and to my knowledge there are no plans to incorporate Gulp into IsoBuild. IsoBuild is core to what Meteor is, gulp and grunt are very powerful automation tools with thousands of possible uses.

Heres a really great starter for gulp, its super simple to get started with: NodeJitsu Gulp tutorial

So, sure, you don't need grunt or gulp, but they could certainly have a productive place in your meteor project and they're definitely worthwhile tools to get to grips with to streamline your dev processes.

If you would like to use either grunt or gulp, this is how I approach structure my project:

Project-folder
    |__ webapp  // my meteor app lives here
    |__ assets  // scss / images / svgs
    |__ node_modules
    | gruntfile.js
    | .eslintrc
    | package.json

I then build, minify, and process my assets, with my target directories in webapp/public

Note that with full npm support coming in Meteor@1.3 this may change, though I'm unclear about whether we'll be able to mvoe this into the project yet.

bigmadwolf
  • 3,419
  • 3
  • 30
  • 44
  • 1
    Thanks pilau, I've been questioning the same thing lately, as I'm a big fan of grunt, and found it to work quite well alongside the meteor build system. It is interesting to me how the assumption around meteor seems to be that its closed and not as flexible as it actually is. – bigmadwolf Jan 12 '15 at 15:34
  • Well said. I myself am relatively new to Meteor; however, I tend to follow the philosophy of using the right tool for the job, for example - Meteor with React, Angular and Browserify, etc.. – pilau Jan 12 '15 at 15:46
  • 1
    absolutely, I think its foolish to believe there are any panaceas in life, and yet so often, there are flame wars of almost religions proportions between framework, language or tool 'devotees'. – bigmadwolf Jan 13 '15 at 08:38
  • That's a good answer. It would be useful if you could suggest the right approach, such as where to place the source files and node modules. I suppose the private directory is eligible for this purpose or, maybe, it would be better the "server" folder? The processed files such as css and js, together with images would be placed in the client folder. Do you thing this would a good staring point? Thanks. – Antonio Pantano Sep 06 '15 at 11:37
  • On it. - will add an example shortly. – bigmadwolf Oct 09 '15 at 09:14