cancel
Showing results for 
Search instead for 
Did you mean: 

[M2.1] - No CLI option to exclude patterns on setup:di:compile and other inflexibilities

0 Kudos

[M2.1] - No CLI option to exclude patterns on setup:di:compile and other inflexibilities

Feature request from adragus-inviqa, posted on GitHub Jul 17, 2016

php bin/magento
Magento CLI version 2.1.0

On previous versions, we've been told to use setup:di:compile-multi-tenant instead of setup:di:compile. K. Now we're told to get back to using setup:di:compile. Ugh, fine.

But whilst you were fixing (?) setup:di:compile, we've gotten accustomed to setup:di:compile-multi-tenant's various and useful CLI options, which - yep - setup:di:compile does not have. And now that setup:di:compile-multi-tenant is gone, we're left with no.. option:

php bin/magento help setup:di:compile
Usage:
 setup:di:compile

Options:
 --help (-h)           Display this help message
 --quiet (-q)          Do not output any message
 --verbose (-v|vv|vvv) Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
 --version (-V)        Display this application version
 --ansi                Force ANSI output
 --no-ansi             Disable ANSI output
 --no-interaction (-n) Do not ask any interactive question

One of the more useful options which is now kaput was --exclude-pattern. That allowed us to omit certain files which we didn't want compiled, ofc. But now we're stuck with whatever you thought it was good for your scenarios.

Can we get setup:di:compile to be as flexible as multi-tenant was? If not the same, at least allow us to inject our own exclude patterns.

PS: I hope I won't be asked "Can you give me an example of a scenario in which you need to exclude something?". Just trust me on this one, mkay?

4 Comments
New Member
Status changed to: Investigating
 
New Member

Comment from choukalos, posted on GitHub Jul 25, 2016

Why are you asking for this - is the primary purpose to improve performance? Or is there another purpose?

If performance and we can save significant time by not re-compiling something, shouldn't we just automatically detect and skip if at all possible? Would that work or as mentioned above there's another reason for keeping exclude patterns?

I'm tracking improvements in compiler performance internally as (MAGETWO-54054). If exclude patterns then that'd need to be another ticket.

Thanks! Chuck

New Member

Comment from adragus-inviqa, posted on GitHub Aug 08, 2016

Hi, @choukalos. Not performance, but an edge case.

I've created a custom installer, emulating the M1-style upgrade scripts. Those scripts are not in a class (but included), and the compiler breaks. I consider the exclusion pattern CLI option to be quite necessary, not only for my own particular scenario, but because there could be many in my situation who want to be able to exclude certain files, for various reasons.

Again, I think it's a little unfair that you hard-code exclusions without giving us a point of extension.

New Member

Comment from choukalos, posted on GitHub Aug 30, 2016

Hi @adragus-inviqa that's for the update.

@piotrekkaminski looks like this one is in your area.