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 piotrekkaminski, posted on GitHub Oct 14, 2015

@tkacheva can you look into it?

[apiuser]

Comment from CRYX2, posted on GitHub Oct 14, 2015

+1 for this improvement

[apiuser]

Comment from jahvi, posted on GitHub Oct 16, 2015

:+1:

[apiuser]

Comment from brendanfalkowski, posted on GitHub Oct 23, 2015

+1. Have used Gulp extensively for M1 and it's way easier for frontend people to understand than Grunt.

[apiuser]

Comment from KAB8609, posted on GitHub Oct 23, 2015

+1 . I believe the majority of Magento Developers are using Gulp vs other build systems.

[apiuser]

Comment from alankent, posted on GitHub Oct 23, 2015

I am not a frontend dev - just wondering what people thought the gaps were. For example, we do some preprocessing of "//@magento_include". Are there other gaps external people know of that we would also need to support?

[apiuser]

Comment from brendanfalkowski, posted on GitHub Oct 23, 2015

This article nails why frontend devs like Gulp better: https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.keufgveaj

1. Grunt focuses on configuration, while Gulp focuses on code
2. Grunt was built around a set of built-in, and commonly used tasks, while Gulp came around with the idea of enforcing nothing, but how community-developed micro-tasks should connect to each other

@alankent Can you explain what you meant by this part?

we do some preprocessing of "//@magento_include"

At the Meet Magento Poland hackathon, I sat with five other developers and tried to trace through the M2 Less includes. We all kind of concluded it's unnecessary and overly complicated to fallback the CSS partials across themes. Also we looked at those commented out //@magento_include statements but had no idea that was processed separately by Grunt.

Aside: the frontend compilation is so unbelievably slow. It took about 7 minutes to rebuild all the CSS + JS + translations, which is a complete dealbreaker for how frontend devs work (make 3-5 changes, save + watcher re-processes + refreshes browser). We're doing that 2-3 times per minute while working.

It would probably take a day of work, but I think a lot of frontend devs will just abandon the Magento-bundled pre-processing for CSS and move everything to a decoupled build process to get around all the complexity. Even having to re-enroll every extension in a non-standard M2 build process, I think it will still be more maintainable and much faster to work with.

[apiuser]

Comment from markoshust, posted on GitHub Oct 23, 2015

There are two main gaps between the two: configuration & speed. Gulp is tremendously faster than grunt. What @brendanfalkowski said; frontend devs won't really work with grunt anymore. To provide an analogy for backend devs, grunt:gulp as svn:git.

[apiuser]

Comment from jahvi, posted on GitHub Oct 23, 2015

I wouldn't mind it if it was just a matter of configuration vs code because most of the time the config is something you tend to do just once and once it's running you forget about it, it's more about speed and compilation times which is something that you have to deal with every time you change your resources.

On Fri, Oct 23, 2015 at 10:07 PM, Mark Shust notifications@github.com wrote:

There are two main gaps between the two: configuration & speed. Gulp is tremendously faster than grunt. What @brendanfalkowski https://github.com/brendanfalkowski said; frontend devs won't really work with grunt anymore. To provide an analogy for backend devs, grunt:gulp as svn:git.

— Reply to this email directly or view it on GitHub https://github.com/magento/magento2/issues/2104#issuecomment-150692786. Untracked with Trackbuster https://trackbuster.com/?sig

-- Ing. Javier Villanueva

[apiuser]

Comment from alankent, posted on GitHub Oct 23, 2015

There is no reason we "dislike gulp" - we just have "grunt" working today. There are just so many things to get done.

I was imagining what might be Magento specific. One thing I knew of was //@magento_include. We use that to search through all modules and allow them to contribute to the Less files for the site. It expands to @include <module>/<path> for every module where that path exists in the module. So that is one "magic" Magento feature. The other one is the path fallback model - we look for files in a series of directories, so themes say can override a file (when @include is used) or extend (when //@magento_include is used).

I don' know Gulp (or Grunt). The challenge seems to be how to integrate Gulp with our fall back rules and special directive, in an efficient manner.