6

I've been using grunt task runner in all of the angular projects I was involved in.

Currently, I found a gulp-protractor-qa plugin for gulp that watches all my element selectors in the tests on the fly. It is good at what it does, but now I have to have a separate gulpfile.js config for the another build system (I cannot find an appropriate alternative among grunt plugins).

Is it okay to use both grunt and gulp build systems in a single project? What are the generally accepted actions in this case?

gulp-protractor-qa is just an example. I can imagine this would hit me again when I would need different suitable plugins in both build systems and would have to make a choice: try to sit on two chairs?

Preview
  • 35,317
  • 10
  • 92
  • 112
alecxe
  • 462,703
  • 120
  • 1,088
  • 1,195

2 Answers2

4

Like you said, if you don't have any other alternative with grunt, I think that the need of using both task runners is real until an equivalent solution is found or created.

You should of course take care of the possible overrides and conflicts that comes with each task you add in gulp, and to me, never mix your watchers. Always choose to use them in one or the other runner cause of the infinite loops. Even if in this case with gulp-protractor-qa you are watching files, there is no dependent task which runs and nothing is written so you should be fine.

Also, since the new dependencies will mainly be the dev ones, the performance of your deployed app will be very slightly affected or not, except if you run your tests on each deploy, that may take a little longer to install them.

Preview
  • 35,317
  • 10
  • 92
  • 112
3

It looks like something is going wrong with running two build systems in one frontend project. You have an option to run grunt tasks from gulp (https://www.npmjs.org/package/gulp-grunt) or vice versa, gulp tasks from grunt (https://www.npmjs.org/package/grunt-gulp). First way looks more efficient, because gulp is much faster than grunt. Consider moving to gulp entirely; many grunt plugins have "native" gulp counterparts.

If moving to gulp seems like an option, but you don't like the idea of spending all that time to rewrite buil config for new tool, try to use some yeoman-genereators. In particular, I'd recommend use of awesome boom generator (npmjs.org/package/generator-boom). It's the best generator for angular with gulp build from the box on the table today.

Victor Suzdalev
  • 2,202
  • 19
  • 28
  • This is an option too. Thank you. – alecxe Sep 19 '14 at 13:27
  • @alecxe one more thing to mention. If moving to gulp seems like an option, but you don't like the idea of spending all that time to rewrite buil config for new tool, try to use some yeoman-genereators. In particular, I'd recommend use of awesome boom generator (https://www.npmjs.org/package/generator-boom). It's the best generator for angular with gulp build from the box on the table today. – Victor Suzdalev Sep 19 '14 at 14:16
  • This is a very useful information and, since I'm very new to gulp, it would help me a lot in the future. Thank you! – alecxe Sep 19 '14 at 14:57
  • Please include the information from the comment into the answer to make it more informative. This would also help other viewers with similar issues. Thanks again. – alecxe Sep 19 '14 at 14:59
  • @alecxe done and you're welcome! I've just had similar issue with two build tools (grunt + brunch) on the same project and it was awful. There are another gulp-powered angular generators, but boom was the only actually working, so I liked it much. – Victor Suzdalev Sep 19 '14 at 20:06
  • Thanks, I've awarded the bounty to Apercu, since this is what that bounty was intended for. But, I'll start another one later in the future. – alecxe Sep 19 '14 at 21:50
  • The biggest challenge I found when switching to gulp is that some 3rd party lint/validators were failing due to not playing nice with streams. We eventually had to write out dummy files for these to still work. – James Oct 01 '14 at 20:21