[1.x] Theme Extender to Allow overriding LESS files

[SychO9]

Fixes #2817

Changes proposed in this pull request:
This PR introduces the ability to just override a LESS file's contents through an extender.
This is mainly useful for theme development, as there are times in extensively customized themes where overriding the actual file makes a huge difference vs overriding CSS styles which can turn into a maintenance hell real fast.

Reviewers should focus on:

• Would we rather have these methods in an existing extender such as Frontend.
• Are we okay having a clear separation of what is a file source and an imported file ? or would we rather abstract that into just overrideFile. I'm personally okay with having this separation, I believe extension developers should understand the difference.

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).

[askvortsov1]

Before getting into the code, what are some use cases for this? Isn't overriding already possible by just specifying new less after the first set

[davwheat]

Yes, but I believe that results in duplicated styles.

If we take

// styles.less
a {
  color: red;
}

// theme.less
a {
  color: blue;
}

...we end up with both separate styles in the compiled CSS one after the other. Less doesn't merge them into one selector and remove the unused property-value pair.

https://beautifytools.com/less-compiler.php

[SychO9]

Before getting into the code, what are some use cases for this? Isn't overriding already possible by just specifying new less after the first set

I'm glad you asked, made me think about this some more, and here are the pros and cons of having this.

Pros

• As mentioned above, there wouldn't be any code duplication.
• I've recently faced a situation where the LESS preprocessor runs out of memory, it seems like my custom theme (being a theme) adds a lot more to preprocess which is too much to handle, having this extender would help with that to a certain extent (ref: https://discuss.flarum.org/d/28458-php-fatal-error-memory-exhausted-in-lesscache-file/2).
• Overriding styles is more tedious than overriding files. When you're designing an element, you would normally rather start from a blank canvas, than a styled element. With an already styled element you have to first override and undo the styles you do not wish to have, only then can you start shaping it, but even then you'd always end up constantly undoing default styles. This mostly applies for more advanced themes. (example: https://github.com/afrux/asirem/blob/851c55516d2ab279928a0a0318ca40d49644dd98/less/forum/DiscussionList.less)

Cons

• If a theme overrides a LESS file and we introduce a bug fix or a feature that changes or adds to that file, the maintainer of the theme would have to adapt their theme themselves.
• Although we can try to avoid the following situation, there are times where simple LESS changes in core between minor releases could break themes that override relevant LESS files if we don't pay attention. For example we could be adding a new class to file1.less and using that class in file2.less. If theme X overrides file1.less but not file2.less, there will be a reference to an unexisting class, which I assume the preprocessor errors out on (that's what it does in dev mode, would be great if we could make it gracefully fail, I'm not even sure it does error out on production, I need to look into this)

[tankerkiller125]

I haven't had a chance to review the code yet, but I agree with the idea in general. I have found theming Flarum to be a royal pain because of trying to override pre-existing CSS and other logic as it stands currently. Letting communities start with a blank slate if that's what they want is the way to go.

[askvortsov1]

When you're designing an element, you would normally rather start from a blank canvas, than a styled element. With an already styled element you have to first override and undo the styles you do not wish to have, only then can you start shaping it, but even then you'd always end up constantly undoing default styles.

This one sold me. I haven't really done theming work, and assumed that most of it is tweaks as opposed to 0-1 work. Will take a look at the code next week when I have access to my laptop again.

[tankerkiller125]

I have not had a chance to test locally, so someone will need to do that.

[askvortsov1]

Could we be a bit more specific as to the expected error message? I'm wary of expecting 500s as that can sometimes provide very little useful debugging info (or could be triggered when other, unrelated stuff is broken).

[SychO9]

might be better to drop this test