Front-end standards group/2016-07-13
Attending: Volker E., Andrew R.-G., Timo T., Trevor P., Jan D., Julien G.
- 1 Social
- 2 Action & Code
- 2.1 New quests
- 2.1.1 T27349 ResourceLoader: Support loading of messages in parsed formats (e.g. parsed, incontentlanguage, ..) (JR)
- 2.1.2 T127268 Dismantle ResourceLoader's "targets" system (JR)
- 2.1.3 T137772 Make more obvious to engineers which ResourceLoader modules are deprecated (JR)
- 2.1.4 T106915 Use Sentry in Production (JR)
- 2.1.5 T138401 Replace jsduck in favor of a better maintained alternative (jsdoc) (JR)
- 2.1.6 T138038 Clearer naming conventions for Non-JS CSS files like `mediawiki.action.history.styles.css` (VE)
- 2.1 New quests
No topics for today.
Action & Code
T27349 ResourceLoader: Support loading of messages in parsed formats (e.g. parsed, incontentlanguage, ..) (JR)
- 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)
- 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)
- 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)
- 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)
- 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)
resources/src/mediawiki.action/history/basic.css or main.css
resources/src/mediawiki.action/history/dynamic.css or interactive.css