[15:14:47] mdholloway: why was https://gerrit.wikimedia.org/r/c/384890/ restored? [16:07:59] bearND: sorry, i'd forgotten to open my IRCCloud tab [16:09:00] my change to get display titles per language variant via the MW API was recently merged and will roll out today: https://gerrit.wikimedia.org/r/#/c/385011/ [16:09:39] adding variant info (specifically, per-variant titles) to the summary response has been blocked on that [16:10:26] i guess adding per-variant URLs (which the restored patch does) wasn't really blocked on that, but i had just been considering variant-related summary items generally blocked [16:11:43] i know there was some discussion of not including the variant URLs, but i don't know if we ever made that decision explicitly [16:11:55] and it was part of the product requirements from coreyfloyd [16:16:01] mdholloway: bearND let me know if we need to sync on variant stuff. It has been off my radar since we have been largely blocked [16:16:29] coreyfloyd: mdholloway: do we really need to add this to the summaries? [16:17:13] Is that what the main issue is? Adding the variant URLs to the summary? [16:17:49] bearND: coreyfloyd: no preference here. if variant titles and URLs are useful to clients, they can be added. if not we should decline the ticket. [16:18:35] So we do need to deal with variants... obviously. But we need to go back and look at it again. I’m not sure where we need to include them yet [16:18:44] We never finished the discussion [16:18:59] Is it ok to chat about this next week or is anything pressing? [16:19:11] bearND: mdholloway ^ [16:20:19] coreyfloyd: bearND: not pressing. i'll -1 or -2 the patch in the meantime [16:20:28] coreyfloyd: E.g. zhwiki has 9 language variants configured (including the default variant). This is information that's the same for every page, so I think it would be wasteful to add to the summary of every page. I think we can hold off until next week. It's just once we add it then we should continue supporting it. [16:26:04] bearND: sounds reasonable... let’s figure it out next week - probably good to start thinking of it again anyways since variants are getting close to shipping [16:28:28] coreyfloyd: moved the ticket back to 'blocked' [16:29:49] mdholloway: thanks! [16:35:17] mdholloway: about https://gerrit.wikimedia.org/r/c/425829/: are you running `npm run -s lint` or something else? Do you have a package-lock.json file? [16:36:08] I'm on v6.12.2 [16:38:01] no, i have been deleting package-lock.json and actually just created an .npmrc file with 'package-lock = false' to suppress it. yes, i'm using `npm run -s lint` [16:40:04] mdholloway: Ah, I finally found the issue in my environment. Something got messed up with my eslint installation. It never ran :( [16:40:21] On the bright side, I can finally repro the lint errors :) [16:40:48] bearND: ah, ok :) [16:40:53] i think i found the upstream change, btw [16:40:54] https://github.com/gajus/eslint-plugin-jsdoc/commit/323a13354257da2862a1d154c32c1c84e5799ec4 [16:42:23] mdholloway: I'm actually getting even more lint errors than you now [16:42:54] lol [16:42:57] oh well, I'm going to merge this one for now. [16:43:17] let me scrap my node modules and start again and see if we can reach lint error parity! [16:43:34] mdholloway: 1030 problems (1030 errors, 0 warnings) [16:43:34] 978 errors, 0 warnings potentially fixable with the `--fix` option. [16:43:40] ! [16:44:03] that's with `npm run -s lint`? [16:44:19] mdholloway: I ran `eslint --cache --max-warnings 0 --ext .js --ext .json .` [16:44:52] when your lint patch was checked out [16:45:16] mdholloway: hmm, but `npm run -s lint` is quiet [16:45:58] mdholloway: although both should be equivalent when looking at the script in package.json [16:46:43] oh, are you running eslint from a global install that's getting different config settings? [16:46:59] with the full command, i mean? [16:47:04] that would explain the discrepancy [16:53:03] mdholloway: that would explain it.