Front-end standards group/2020-06-24

Attending: Itamar Givon, Lucas Werkmeister, Jakob Warkotsch, Tonina Zhelyazkova, Joe Walsh, Ed Sanders, Eric Gardner, Stephen Niedzielski,  Jan Drewniak, Volker Eckl, Anri Bolon, Roan Kattouw, Anne Tomasevich, Sarai Sánchez

New quests

 * Self-closing tags rewrite needed and shorthand syntax: [RK]
 * Using RemexHtml 598133 instead of PHP's HTML Parser – In practice, this change means:
 * Before: self-closing tags like  or   work
 * After: self-closing tags break, so instead you have to write  and
 * Before: shorthand syntax doesn't work, so you have to write
 * After: shorthand syntax works, so you can write
 * Putting it together: we used to write, now we will write
 * There are lint rules to enforce this: https://github.com/wikimedia/eslint-config-wikimedia/pull/298 – people should update their eslint config versions to benefit from new rules
 * When writing a Vue component, write  above your   statement to get linting
 * ES: […] Generally one should avoid eslint warnings; to make warnings into errors, you'd have to add max-warnings=0 which some do
 * Have a look at the test fixtures to see what is considered valid/invalid: https://github.com/wikimedia/eslint-config-wikimedia/tree/master/test/fixtures


 * Lil discussion about general rules how to write Vue yet, with some early decisions and orientation on  default Vue guidelines. Future plan: Manual:Coding conventions/Vue.js alongside eslint-config-wikimedia
 * Folks seem generally happy with short-hand syntax for now


 * Newly started OOUI component migration path outline Vue.js/OOUI migration guide [SN]
 * ES: Clarify “Avoid inheritance”. OOUI Mixins (f.e. ButtonElement) are useful not to repeat yourself
 * EG: Vue doesn't really follow an inheritance paradigm. Vue mixins has private state too
 * Some discussion about when to keep components in individual projects and when to contribute them to the library; some considerations:
 * don’t want to slow down project development
 * don’t want to slow down library development
 * early library development gives others more opportunity to give feedback on the components before they solidify
 * using the library in production brings additional responsibilities for library development
 * proposal: start a first pull request for one component soon!
 * Phab ticket per component
 * Action: Create Phabricator tasks to keep track of features that new components are still missing compared to OOUI (when they’re not in scope for the initial PR)


 * Eslint works, stylelint doesn't


 * WMDE is building a separate component library specific to Wikibase. Design is mostly aligned with WMF design, process for technical alignment is still in progress. Experience: When different feature teams contribute to the same library without consulting UX, it leads to a lot of confusion and components that cannot be used because they don't comply to design.
 * Action: Involvement in exemplatory component PR discussion for WVUI