Page MenuHomePhabricator

[Spike 4hrs] Evaluate splitting LESS into separate CSS entries
Closed, DeclinedPublic0 Estimated Story PointsSpike

Description

Questions to answer

  • Identify pros and cons of generating Webpack CSS entries based on JavaScript CSS imports. Consider writing a prototype patch to help shape this effort.
  • Answer the question: is there _weird_ LESS variable synchronization concerns (tm) with Core? Some of these have been moved into wikimedia-ui-base. How does mediawiki ui fit into this?
  • Do we think there's much risk with LESS compiler or css-janus version mismatches in Core?

Outcome

Please write up your findings on mediawiki.org under Reading/Web/Loading CSS in webpack for mediawiki

Event Timeline

Jdlrobson renamed this task from Evaluate splitting LESS into separate CSS entries to [Spike] Evaluate splitting LESS into separate CSS entries.Mar 15 2018, 3:33 PM
Jdlrobson triaged this task as Medium priority.
Jdlrobson updated the task description. (Show Details)
ovasileva renamed this task from [Spike] Evaluate splitting LESS into separate CSS entries to [Spike 4hrs] Evaluate splitting LESS into separate CSS entries.Mar 28 2018, 4:17 PM
ovasileva moved this task from Triaged but Future to Upcoming on the Web-Team-Backlog board.
Jdlrobson set the point value for this task to 0.Mar 28 2018, 4:20 PM
Jdlrobson subscribed.

(to signal we talked about it adding 0 story points)

Niedzielski added a subscriber: ovasileva.

@Jdlrobson, @ovasileva, I think we need to work on this spike to know whether or not we should touch the LESS files in MobileFrontend. I propose we bring it onto the board soon.

The layer of indirection provided by Webpack for JavaScript is very useful. It would be excellent to have the same kind of flexibility in our styling code if it doesn't interfere with ResourceLoader. Our way forward with JavaScript is clear: just stick to the existing ResourceLoader module structure. However, we haven't invested much time yet in figuring out how styles play into the investment project. Investigating now seems timely and avoids overlapping work in mobile.startup JavaScript. This work would be independent and no risk given that no code should be merged as part of this spike.

Might be worth reflecting on how this went in Popups. To be honest I didn't feel the change in Popups provided many benefits.

Shall we talk about this on Monday? It already looks like a css based agenda!

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptAug 2 2019, 4:57 PM

Not a priority right now. Particularly given the build step discussion for WVUI