[00:42:31] Krinkle: I'm about to start cleaning up for https://phabricator.wikimedia.org/T72470 any point before I launch the rocket? [00:48:54] Amir1: you mean pointers/advice? [00:49:12] yeah, anything I need to keep in mind [00:52:25] Amir1: ok, here goes. in no particular order, things I've encountered when personally migrating scripts related to wg vars [00:53:10] In general, what we're aiming for is scripts that access a global variable that should instead be accessed via mw.config.get. [00:53:33] these can also sometimes be accessed via window.wgFoo, although far less common, it does happen at times. [00:53:54] Especially in conditionals because property access yields falsey undefined if unknown, instead of throwing a ReferenceError [00:54:20] e.g. if (window.wgIsMainPage) works, if(wgIsMainPage) does not. [00:54:44] unless you'd do (typeof wgIsMainPage !== undefined && wgIsMainPage) [00:54:49] anyway, so that. [00:55:09] now, as for why you shouldn't just regex wg[A-Z] with mw.config.get('$1') … [00:55:54] people can be using local variables that have those names. e.g. var wgMyGadgetSpecialOption = true; [00:56:45] global variables are often used as a way for user scripts to influence/configure a gadget. [00:57:21] e.g. inside a gadget it might say: var doFancyStuff = window.hotcat_do_fancy_stuff === undefined ? true : window.hotcat_do_fancy_stuff; [00:57:28] yeah, I go with hard list of our variables like wgServer, etc. [00:57:31] then in your common.js you can change the default by setting window.hotcat_do_fancy_stuff= false ahead of time [00:57:35] yep, exactly [00:57:42] but.. [00:57:50] var wgTitle = mw.config.get('wgTitle'); [00:57:52] is also not uncommon [00:57:58] especially now post-migration [00:58:06] so beware of scope [00:58:12] can be hard to tell at times [00:58:20] especially if they modified it since then [00:58:34] noted [00:58:43] and function params like function (wgTitle) { [00:58:52] so if you then ingore that inside he function with mw.config, it's not the same anymore [00:59:01] objec keys and property access as well [00:59:07] { wgFoo: unrelated } [00:59:19] and mw.hotcat.context.wgFoo =unrelated [01:00:01] lastly, if you use any form of semi-assited automation, you'll probably want to incorporate a lexer or linter of sorts. [01:00:02] noted [01:00:17] yeah semi-automated [01:00:23] in my tourbot script I use `acorn` from npm, to ensure no parser errors afterwards (and beforehand) [01:00:31] since we don't lint during save on -wiki [01:00:35] not even for basic syntax [01:00:49] if you're feeling YOLO, you could e.g. paste the scrit in teh browser console and see that it doesn't throw [01:00:49] (maybe we should?) [01:01:00] but you know, maybe not with stuff you don't trust or regularly maintain :) [01:01:08] especially if you hve special rights and are on a wmf wiki page [01:01:20] yeah, not going to try that [01:01:35] Amir1: yeah, if people stop using .js personal pages for magic protection reasons with non-js content [01:01:58] lol [01:01:58] we should probably implemenet something like User:Example/.protected/• or something like that [01:02:14] or go full-on with a way to protect pages you "own" [01:02:35] but then you need to tell gadge users to protect User:example/huggle.yaml manually [01:02:41] automatic by convention seems useful? [01:02:44] anyway :) [01:03:51] https://phabricator.wikimedia.org/T76204 for refernece [01:04:09] a big chunk of use cases were gadgets/tools storing .json [01:04:18] which we since fixed by allowing .json personal pages that are auto protected [01:04:29] but we haven't really driven tool authors to adopt that [01:04:38] plus you have some random things that have .ini or .yaml syntax [01:06:58] ini. Nice [01:07:09] Huggle C# etc [01:07:31] "Mess" would be an understatement here