Apologies if I'm missing something that makes this so complicated but could we not simply throw an error/warning if you use addModuleStyles on a module with scripts set and leave this problem to the engineer to solve?
e.g. force 'a.lib' => [ 'styles' => [ 'a.css' ] 'scripts' => ['a.js'] ]
to become 'a.styles' => [ 'styles' => [ 'a.css' ] ] 'a.lib' => [ 'dependencies' => ['a.styles'], 'scripts' => ['a.js'] ]
This will obviously require lots of fixes in extensions using the old method but we've been here before when we enforced style modules having to set a position.
On Wed, May 4, 2016 at 9:44 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Wed, May 4, 2016 at 8:23 AM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, May 4, 2016 at 6:34 AM, Krinkle krinklemail@gmail.com wrote:
[1] If one would allow page style modules to have dependencies and
resolve
them server-side in the HTML output, this would cause corruption when the relationship between two modules changes as existing pages would have the old relationship cached but do get the latest content from the server. Adding versions wouldn't help since the server can't feasibly have access to previous versions (too many page/skin/language combinations).
But don't we have the corruption anyway? Say page Foo has a page style module 'foo', so it calls addModuleStyles( [ 'foo' ] ). Then module 'foo' is changed so it also needs 'bar', so page Foo now has to call addModuleStyles( [ 'foo', 'bar' ] ). What is avoided there that isn't avoided when addModuleStyles( [ 'foo' ] ) is smart enough to internally see that 'foo' depends on 'bar' and act as if it were passed [ 'foo', 'bar' ]? Or what case am I missing?
On the other hand, dependencies avoid the case where the developer modifying 'foo' doesn't realize that he has to search for everything everywhere that passes 'foo' to addModuleStyles() and manually add 'bar' to each one.
Hmmmm... wait, does load.php not resolve dependencies server-side when producing concatenated CSS output? That would seem to break the transitional model I proposed if so.
Ah, fun. :)
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l