Front-end standards group/2016-07-13

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

Social
No topics for today.

T27349 ResourceLoader: Support loading of messages in parsed formats (e.g. parsed, incontentlanguage, ..) (JR)
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)
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)
https://phabricator.wikimedia.org/T137772 ==> JG will write up thoughts of the group on this task
 * 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.

T106915 Use Sentry in Production (JR)
https://phabricator.wikimedia.org/T106915 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.
 * 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.
 * 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)
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)
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