Skip Luma theme when compiling static resources

[apiuser]

Feature request from devdesco-ceo, posted on GitHub Jan 19, 2016

I have a situation where I have custom theme (Porto, based off blank theme) installed and active, and prepackaged Luma theme is not active anywhere in my Magento stores, so no need to trigger compilation on it. BWT when I run static content compiler, both Magento/blank, Magento/luma and Smartwave/porto are being compiled. That would be fine, but I am compiling 6 locales for my multistore/multilang setup, and that takes awhile, believe me!

The command I trigger: php ./bin/magento setup:static-content:deploy en_US fr_FR de_DE pt_PT es_ES it_IT

What can I do to pass a command to compiler to skip compilation of Magento/luma?

[apiuser]

Comment from erikhansen, posted on GitHub Mar 03, 2016

+1 for a solution. We've run into this issue on a site with 5 locales and two custom themes. Having to compile the magento/blank and magento/luma themes doubled the setup:static-content:deploy time.

I would prefer an "exclude" flag be added (as opposed to "include"). Since the exclude flag will likely be hard-coded into deployment scripts, being able to specify which themes to exclude seems more useful. Some thing like this:

bin/magento setup:static-content:deploy --exclude=magento/luma,magento/blank

[apiuser]

Comment from alankent, posted on GitHub Mar 04, 2016

As a workaround, has anyone looked at using https://github.com/SnowdogApps/magento2-frontools with Gulp to generate the theme files for production? You list theme names and locales to compile, so easy to skip combinations you don't want. I was just not sure if it did everything for production (I have not tried it), but I would love to understand if there are any gaps.

[apiuser]

Comment from erikhansen, posted on GitHub Mar 04, 2016

@alankent I love how creatively you think about problems like this. I tend to try and stick with native tools for things like deploying to production, as they tend to be more stable/trustworthy. I am planning on reading through your blog posts about using Gulp for development to see what benefits it offers.

[apiuser]

Comment from alankent, posted on GitHub Mar 04, 2016

We need to improve the performance of our native tool. But Gulp is clearly faster and more interactive during development. I am honestly curious to see if it can do the full production deploy. Then it can be "use our built in tools if you don't want to think; use Gulp if you are willing to install one extra tool for a better development experience".

But to be clear, this is not my project - @Igloczek kicked it off and did all the work. I just made some suggestions along the way. If there were gaps moving to production, I was going to suggest to him to fix those problems as well ;-). The idea was more along the lines of "use the same tool during development and production, so the CSS files are identical". I think this is more important than using our "official" tool. It also means I assume you can use any gulp optimization plugins, and you can get more control over manual CSS file merging.

(And I have a final draft of a ebook on themes in the wings undergoing final review - if this works all the way to production, I may sneak that into the book as well.)

[apiuser]

Comment from erikhansen, posted on GitHub Mar 04, 2016

@alankent Yeah, it makes sense to use the same compilation technology in development and production to ensure consistent results. Per your previous question, I am curious to see if anyone is using https://github.com/SnowdogApps/magento2-frontools in development and production and to see how that is going for them. Maybe a tweet from you would get more feedback than this obscure ticket.

[apiuser]

Comment from alankent, posted on GitHub Mar 04, 2016

I might try that in a few days - I was hoping people expressing pain on this thread would be more motivated to give it a try - they had real world problems that are known to be bad, so if it works for them then that is a big thumbs up with concrete data.

[apiuser]

Comment from Igloczek, posted on GitHub Mar 04, 2016

@alankent Thanks for mention, but "Frontools" unfortunately are not 100% substitute of setup:static-content:deploy - I focused on styles compilation and this part works as expected, but there are also RequireJS and templates processing inside this CLI command and for now I'm not supporting it.

[apiuser]

Comment from Igloczek, posted on GitHub Mar 04, 2016

BTW. I forgot about little thing to do - I said in comments of some your blog post about --no-styles flag to this CLI command and I'm going to do this ASAP as PR to main M2 repo.

So, if you use setup:static-content:deploy --no-styles [...] + Frontools -> deployment process should be a lot faster.

[apiuser]

Comment from erikhansen, posted on GitHub Mar 08, 2016

I just finished writing Capistrano scripts to automate a Magento 2 build that we're launching tomorrow. The site has three custom themes + the two native themes. The total build process takes ~19 minutes, ~18.3m of which is running the bin/magento setup:static-content:deploy command. Being able to exclude the magento/blank and magento/luma themes from the command would remove ~7m from the deploy time. This should be fairly simple to implement and it would be good to know whether this is something Magento has on their roadmap and/or whether they would accept a PR to implement this functionality (I'm looking at all of you others that are experiencing the pain of this).

[apiuser]

Comment from devdesco-ceo, posted on GitHub Mar 08, 2016

Nice! 1+