Front-end standards group/2016-07-13

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

No topics for today.

Action & Code

New quests

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

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)

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)

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

Social