Reputation: 474191
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?
Upvotes: 6
Views: 710
Reputation: 2212
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.
Upvotes: 3
Reputation: 35846
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.
Upvotes: 4