replace grunt with gulp

[apiuser]

Feature request from markoshust, posted on GitHub Oct 13, 2015

Grunt has a very slow building process. Gulp should replace Grunt as the recommended method for building static assets.

This would also be a good time to decouple PHP calls from the nodejs build process. Any PHP calls from nodejs should be moved to ./bin/magento so node/js code is kept node/js only, and PHP scripts are only called from PHP. This will help streamline the deployment process.

[apiuser]

Comment from pawel-dubiel, posted on GitHub Jan 06, 2016

+1

Currently it seems almost impossible todo any serious work in timely manner. I have to wait a minute to rebuild all locales. Would be interesting to hear from others how they improve development speed and make the whole thing less painful.

[apiuser]

Comment from code-K, posted on GitHub Jan 08, 2016

+1 for this improvement

[apiuser]

Comment from Oregand, posted on GitHub Jan 21, 2016

+1 for this, gulp would make the development for the fronted JS & CSS much faster.

You guys have built an amazing project here with 2.0, lets just make it a tiny bit better!

[apiuser]

Comment from alankent, posted on GitHub Jan 21, 2016

To be clear, is the request for Gulp because you want Gulp functionality, or the request for faster performance whatever way it is possible? From comments it sounds like desire is for performance, not Gulp specifically.

[apiuser]

Comment from markoshust, posted on GitHub Jan 21, 2016

@alankent grunt is an old tech, gulp is a newer one. there is no way to achieve even close to the performance of gulp with grunt. grunt : svn, gulp : git. it's like trying to make subversion faster than git, when it's not even remotely possible. grunt really sucks for frontend devs right now, it's aged (and already dead to frontend world). this just needs to happen.

[apiuser]

Comment from alankent, posted on GitHub Jan 21, 2016

Background: I was brainstorming on this one a bit, browsing Gulp code etc. One of the issues is my personal ideal experience is to not have to list dependencies etc at all - why not have Magento work out what themes, locales, etc exist. I was trying to work out if getting something merged into Gulp was important vs doing something custom where it knows more about Magento's fallback schemes, theme structures, etc. The end result could be less work to implement if custom (we would use standard Less processors etc). But it would be zero configuration (and thus zero extensibility). Hence I was trying to understand if it was speed that mattered or Gulp. Would people prefer doing more manual configuration and have a standard tool, or zero configuration but no ability to use for anything else that Gulp can do. (I was trying to not bias people's thinking.)

Hence the question - do people want Gulp or do people want speed?

[apiuser]

Comment from brendanfalkowski, posted on GitHub Jan 21, 2016

@alankent: I believe the import order is the load order of modules, which uses dependency information in modules.xml to determine the ordering (like all other cases). That is, app/etc/config.php order is worked out, then everything just uses the order in that file.

@alankent: So how to control what Less files get loaded or not loaded? You just load (or not load) a module. You don't have to write a Less file that lists all the modules you have loaded for your site and maintain that file.

For CSS, the order that libraries, resets, vars, mixins, utilities, layouts, patterns, modules, and pages are loaded matters. It can't follow an arbitrary order determined by PHP modules. If Magento 1 did this, none of the sites I've built in the last five years would work, be as maintainable, or as lean.

@markoshust grunt really sucks for frontend devs right now, it's aged (and already dead to frontend world). this just needs to happen.

This is accurate. The people using Grunt today are invested in it previously. Every grunt vs gulp comparison has the same conclusion: if you like grunt it's good, but you'll like gulp better if you care to update. So nobody fresh picks grunt today. And now NPM scripts is apparently gaining traction as an even leaner approach than gulp.

@alankent: One of the issues is my personal ideal experience is to not have to list dependencies etc at all

This just doesn't line up with how frontend devs use Grunt/Gulp and prefer the simple/extensible nature of listing things. It's very very easy to turn things on/off this way and put them in the right order. Autoloading makes it a mess because CSS preprocessors do not have a dependency definition schema. You have to architect this and be somewhat smart about it.

@alankent: Would people prefer doing more manual configuration and have a standard tool, or zero configuration but no ability to use for anything else that Gulp can do.

Definitely standard build tools is preferred. This is how frontend devs are capable of working with basically any platform. Imagine if every PHP project had their own twist to Composer that wasn't compatible.

@alankent: Do people want Gulp or do people want speed?

Both :+1: — and without the Magento flavored stuff. Keeping it agnostic makes it better for frontend devs.

[apiuser]

Comment from mackelito, posted on GitHub Jan 22, 2016

Should really magento be pron of any of these tools?

I use gulp and would love to see this change from grunt.. but I think the "problem" runs deeper.. like the choice of less.. gotta say that I like scss better and would love to use that together with npm instead!

[apiuser]

Comment from hrvojejurisic, posted on GitHub Jan 22, 2016

Honestly... I've been bitching about this for more than a year now.

Less, sass, grunt, gulp, npm, post-processors... you may continue the sequence. And who can guess what will be "hot" frontend tool or technology in the next couple of years?

IMHO, Magento shouldn't integrate pre-processing in the system at all. I can see my self ( and most of frontend devs I know ) abandoning Magento 2 "best practices" and implementing my own, decoupled system ( probably sass with gulp ), similar to what we had in Magento 1.

[apiuser]

Comment from mackelito, posted on GitHub Jan 22, 2016

Agreed! Perhaps we should create a open git repo for such a setup?