MediaWiki

Front-end standards group/2016-07-13

< Front-end standards group

Attending: Volker E., Andrew R.-G., Timo T., Trevor P., Jan D., Julien G.

Social

edit

No topics for today.

Action & Code

edit

New quests

edit

T27349 ResourceLoader: Support loading of messages in parsed formats (e.g. parsed, incontentlanguage, ..) (JR)

edit

https://phabricator.wikimedia.org/T27349

  • TT: Last discussed in May 2016. No activity yes. Maybe move back to Inbox for next meeting when JR is present.

T127268 Dismantle ResourceLoader's "targets" system (JR)

edit

https://phabricator.wikimedia.org/T127268

  • TT: Origin were use cases in Reading.
    • Static analysis hard
    • Unsure whether dep are blocker. TT thinks in theory it shouldn't be hard to /not/ load them.

T137772 Make more obvious to engineers which ResourceLoader modules are deprecated (JR)

edit

https://phabricator.wikimedia.org/T137772

  • TT: Task description; Make obvious that module is deprecated, sending to console somehow. This would apply to the whole module.
    • Makes sense
  • TP: Let's avoid putting it into startup manifest, but do inject a script statement when loaded to mw.log it.
    • TP: We should make clear what "deprecate" means on mediawiki.org.
  • JG: Insist on expiration date.
  • TT: 2 types of manifest, a) server-side module registration, b) more generic format for exporting through startup module; what client needs to know when resolving module names and loading them.

==> JG will write up thoughts of the group on this task

T106915 Use Sentry in Production (JR)

edit

https://phabricator.wikimedia.org/T106915

  • AG: Privacy implications?
  • TT: Most(?) NDA only
  • AG: Probably not bringing in everything what we log in console in Sentry. Devs would have to flag what to send to Sentry.
  • TT: It logs uncaught exceptions, not everything going to console.
    How would you flag them?
  • JD: Any performance implications? Or more like a system call when an error occurs?
  • TT: Kind of 'yes' and 'no'. Listens to global window.onerror – browser catches that naturally. But we are not a simple (static) site.

Good stack traces that are /not/ minified.
Would have some small implications on performance.
Would be good to have source maps available in RL before.
Personally think, raw exceptions would be great. We might be able to essentially cover that.

  • TT: Could be rolled out on discovery portal sites first, as they have no deps on RL

T138401 Replace jsduck in favor of a better maintained alternative (jsdoc) (JR)

edit

https://phabricator.wikimedia.org/T138401

  • TP: Maybe work upstream on jsduck or write own plugin
  • TT: Yep, seems doable. While not mentioned in this task, we do have other (perhaps more major) reasons for finding an alternative. Worth investigating.

T138038 Clearer naming conventions for Non-JS CSS files like `mediawiki.action.history.styles.css` (VE)

edit

https://phabricator.wikimedia.org/T138038

Proposals:
resources/src/mediawiki.action/history.css
resources/src/mediawiki.action/nojs/history.css

resources/src/mediawiki.action/history/styles.css
resources/src/mediawiki.action/history/noscript.css

resources/src/mediawiki.action/history/basic.css or main.css
resources/src/mediawiki.action/history/dynamic.css or interactive.css

Retrieved from "https://www.mediawiki.org/w/index.php?title=Front-end_standards_group/2016-07-13&oldid=5140871"