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 markoshust, posted on GitHub Oct 24, 2015

We use that to search through all modules and allow them to contribute to the Less files for the site.

@alankent Why? I agree with @brendanfalkowski -- this entire LESS building process seems to bloated, overbuilt & impractical. No one's going to use it if it takes over a few seconds to build new CSS files.

[apiuser]

Comment from markoshust, posted on GitHub Oct 24, 2015

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 think overriding a file makes sense, but extending a file does not. Can't the same be accomplished by just creating a new less/css file and adding it to the assets being built? I just really don't understand "extending" a less file.

[apiuser]

Comment from alankent, posted on GitHub Oct 24, 2015

"extending" just means "append to the end of". Less forllows the CSS pattern of "last specified rule wins". The question is how to let a module be loaded and contribute the styles it needs to a site. The current approach "plugs in" that additional content, just like modules can plug in PHP code via di.xml, plugins, event observers, etc.

I want to do a little more research on how grunt works now. I was wondering how feasible it was to generate a Gulp friendly Less file, so little tweaks to CSS would be fast (and regeneration required only if files were added or removed). That could then be a CLI command. I just don't know how feasible it is yet.

[apiuser]

Comment from markoshust, posted on GitHub Oct 24, 2015

My question is why do you need to 'extend' the CSS? CSS is not an object-oriented technology. Last rule wins, can't we just leave it up to the module to define which styles it needs to define, since CSS is all merged together when interpreted anyways? A module can always use higher-level node specificity if it needs to traverse up the DOM tree to style an appropriate element. One thing that would help is to be able to define the load order of CSS/JS files (not sure if this already exists). Stylesheets are just text files -- creating a new file is essentially the same as 'extending' an existing file.

[apiuser]

Comment from alankent, posted on GitHub Oct 24, 2015

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.

Just as one module's layout file can change/extend that of the layout files of modules loaded previously (e.g. module A adds a footer, module B adds a side bar, module C removes the side bar and adds a different one), modules (and themes) contribute to the CSS to be generated for a page (and can override CSS of previously loaded modules, allowing for example a system integrator to write a custom module for a site and have the "final word" on what styles will be used.

For example, the Magento UI library (a set of Less files defining buttons etc) uses lots of variables. You can change the color of lots of things just by changing a single variable. Variables follow the "last rule wins" rule as well. You cannot set the variable in a separate CSS file - it would not globally affect all buttons then. Remember Less variables you can use for things like lighten(@button_color,25%), so by setting one color you can change the whole theme (including shaded out colors, highlights, etc). So it is not lots of little CSS files that get imported, but rather lots of Less files that get compiled into a single CSS file that gets imported (which can also be minified).

For example, if you look at https://github.com/magento/magento2/blob/develop/app/design/frontend/Magento/blank/web/css/styles-l.... you will see it imports a few things, then finally //@magento_import "source/_extend.less";. The idea is this allows all modules to contribute to rules (e.g. add new widget related Less), but still have the ability to have a final say in _extend.less, which is a true "final say".

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.

[apiuser]

Comment from markoshust, posted on GitHub Oct 24, 2015

Thank you for the detailed explanation -- makes a lot more sense now

[apiuser]

Comment from alankent, posted on GitHub Oct 24, 2015

Nothing like trying to explain something to force yourself to learn it! (To be honest, I still don't understand all the rules - we have modes like client side Less compilation, where we make all the individual Less files available for download by the browser, so it does the compilation. I am still trying to understand all the subtleties myself.)

[apiuser]

Comment from markoshust, posted on GitHub Oct 24, 2015

Having sort ordering was always a prob in m1, so this will actually completely fix that. Really like that now that I know what is going on (and why)

Where is the magic @magento_include being processed?

Edit: Never mind, was searching for @magento_include instead of @magento_import. Thanks a lot @brendanfalkowski

[apiuser]

Comment from alankent, posted on GitHub Oct 24, 2015

If you mean in the source code, I use "grep -r" myself to find it! I don't know how the code works to be honest - there are multiple modes going on (client side compilation, server side on demand, precompiled, grunt, etc). I have not looked at the actual code that implements it.

[apiuser]

Comment from CyberCookie, posted on GitHub Dec 24, 2015

+1 for this improvement. Just give us chance to do simplest changes in 1-2 sec. It's not a modern approach to wait for less build more than 6 sec as example, when you do changes every 5 sec in css and must watch all changes instantly. Developing must give pleasure but no pain.