@context is a jsduck custom tag used in very few places.
Rename to @this to make migrating to JSDoc easier.
Change-Id: I10394e85354b7002d96e0fa1af1cb7ae7534db8d
Was first attempted in f1eaa06d5e,
and reverted in 0b3fe4fe8c. Now this
is done in eslint-config-wikimedia for all repos.
Change-Id: I9ee735eef40085b6373b565838d67e186e438657
This reverts commit f1eaa06d5e.
Reason for revert: accidentally allowed ES6 syntax.
Looking for a way to redo this that doesn't break our linting as badly.
Change-Id: I78974b97001bdbea9aff5717c69d71b8a2582ade
Install eslint-plugin-vue, which lints JS inside <script> blocks in
.vue files, and also lints Vue templates. Configure eslint and stylelint
to run on .vue files. stylelint automatically picks up on CSS in <style>
tags.
You may have to change a setting in your text editor or IDE to make it
run eslint and stylelint in .vue files. For eslint, see
https://eslint.vuejs.org/user-guide/#editor-integrations ; for
stylelint, I had to install the linter-stylelint-plus Atom plugin then
add source.css.embedded.html to the "Base Scopes" setting for that
plugin.
Change-Id: I7e6a13317792fc25c29106739b0c24864fd8d301
This aims to disallow using the methods listed below, which are
supported by Chromium 69 but not supported by Internet Explorer 11.
Most of them were introduced in ECMAScript 6, but some are more recent
or experimental.
We keep breaking IE 11 support by using them. Recent examples include:
* mediawiki/core:
Ic85063dfbbcf26a99d343845c9fb801f1888d750
* mediawiki/extensions/MultimediaViewer:
I0954c42a37668b0eb46c3e864a2e13152a6dc68a
* mediawiki/extensions/UploadWizard:
I70d37a8f0abcc96b5e39fa71a93cda6f3421c87c
* VisualEditor/VisualEditor:
Ic1971549da37091c41a847229d18e95aff5c9952
This will unfortunately almost certainly cause false positives, but
hopefully not too many of them. Common false positives can be
disallowed more precisely using 'no-restricted-syntax' rather than
'no-restricted-properties'.
Disallowed methods:
String.prototype:
codePointAt
endsWith
includes
normalize
padEnd (ES 2017)
padStart (ES 2017)
repeat
startsWith
trimEnd (experimental/proposed)
trimLeft (experimental/proposed)
trimRight (experimental/proposed)
trimStart (experimental/proposed)
Array.prototype:
copyWithin
entries
fill
find
findIndex
flat (experimental/proposed)
flatMap (experimental/proposed)
includes (ES 2016)
keys
values
String:
fromCodePoint
raw
Array:
from
of
Object:
assign
entries (ES 2017)
getOwnPropertyDescriptors (ES 2017)
getOwnPropertySymbols
is
values (ES 2017)
I compiled the list based on running the following code in each
browser's console, since there doesn't seem to be an authoritative
list anywhere on the Internet:
console.log( Object.getOwnPropertyNames( String.prototype ) )
console.log( Object.getOwnPropertyNames( Array.prototype ) )
console.log( Object.getOwnPropertyNames( Object.prototype ) )
console.log( Object.getOwnPropertyNames( String ) )
console.log( Object.getOwnPropertyNames( Array ) )
console.log( Object.getOwnPropertyNames( Object ) )
Change-Id: Ic44c79834f99c52863fbc544ad657787f70fb9bb
Follows-up Id6d13bbea6:
- '$': mw.loader.implement does this already.
- 'mw': Use the canonical name directly.
This replaces the following patterns:
File closures (common):
- `( function ( $, mw ) {` => `( function () {`
- `( function ( $ ) {` => `( function () {`
- `( function ( mw ) {` => `( function () {`
- `( function ( mw, $ ) {` => `( function () {`
File closures (rare):
- `( function ( mw, $, OO ) {` => `( function () {`
- `( function ( mw, OO, $ ) {` => `( function () {`
- `( function ( mw, document ) {` => `( function () {`
Combined dom-ready and file closure (rare):
- `jQuery( function ( $ ) {` => `$( function () {
- `jQuery( function () {` => `$( function () {
Remaining references in files without a closure, as found by
the new ESLint setting (rare):
- `jQuery` => `$`
- `mediaWiki` => `mw`
Change-Id: I7cf2426cde597259e8c6f3f6f615a1a81a0ca82b
Even though Array.prototype.forEach only works on arrays, and
$.each is more generic, I think it makes sense to begin discouraging
the usage of $.each now. This can be overriden by ignore lines or
by Array.prototype.forEach compatible lines. This doesn't seem too
much of an ask of engineers and helps future migrations
Bug: T200877
Change-Id: I339cff311a830699c8e32f07cec338a39870c53f
Also prevent further usage by an eslint rule.
jQuery.proxy is deprecated:
* https://github.com/jquery/jquery/issues/2958
Bug: T200877
Change-Id: I3a4977f9b90c2104db320d2d939a1cbaa1819de0
Replace jQuery.inArray with Array.prototype.indexOf.
Also enforce this via eslint rule.
Bug: T200877
Change-Id: Idbd06e6a1681300c4ab9142c7b57e4376f474041
== jQuery
ResourceLoader wraps and executes all modules in the system via
a closure that explicitly binds '$', 'jQuery'. This means there is
no point in aliasing jQuery to $ in every single file.
ResourceLoader already does this.
This is a very very old habit that was introduced in 2009 when we
didn't have ResourceLoader and were concerned with wikis loading
their own copy of jQuery that could redefine the global 'jQuery'
and '$' variables. We simply hoped that "our module" initialised
before "that module" cache the reference we got in the file closure.
Then in 2010, when building ResourceLoader, we found this didn't
always work. And we also sometimes forgot to add the closure.
Which is why in 2010 (before ResourceLoader went to prod, in 2011)
we fixed the above issue in ResourceLoader itself by "magically"
providing a private binding to '$' and 'jQuery' in every
mw.loader.implement() closure. (r79246, bd93eeb85).
So, these in-file closure references are redundant.
And have been since 2010.
== jQuery, again.
While redundant, they remained in most files. Harmless, right?
However, that same problem of duplicate jQuery copys on a page
came up again in 2013. Why did our magic binding not work?
It was *because* the file also did its own binding:
1. ResourceLoader stores reference to proper jQuery.
2. ResourceLoader provides private reference to it as '$'.
3. .. time passes ..
4. Module executes, and is given the proper jQuery via the
private '$' reference. The module file ignores this because
it instead looks up current jQuery, and caches that.
So, we expande the magic binding to also bind the name 'jQuery'.
(2013-2014; 5742c1f385).
== mediaWiki
We export the binding as 'mw' and 'mediaWiki'. We internally
mostly use 'mw' (in HTML, and documentation, and the canonical
name in the JSDuck index). But, rather than using the shorter name,
we use the longer name and alias it in every single file.
There was never a concern about this global being redefined
as far as I know. However, if that happens one day, we should..
provide a magic binding for it.
Change-Id: Id6d13bbea6927a4c7354ca1edd98f13f0fae30c1
Follow up to I4552191f639b1022cb085ef5eb4abda835c2d91c
* Add eslint-ignores to various files
* Correct various uses of isFunction, trim, map, grep
where easy fix is available
* Switch from eslint warning to error
Bug: T200877
Change-Id: I8420db21e548772332e51769aa8ec92d5958715f
For time being these messages will warn.
In a follow up, I plan to fix issues and
add eslint-ignore lines and make this
error rather than warn.
Bug: T200877
Change-Id: I4552191f639b1022cb085ef5eb4abda835c2d91c
Follows-up c0fb8a8836, I890e6e49b.
* Disable 'qunit' env in general source code. And re-declare
locally in the few src files that use it properly.
* Create separate eslint config for tests/qunit with various
rules disabled (e.g. valid-jsdoc and es3-keywords).
Change-Id: I37ccec2019de55edfee92697eb80478df7cb6220
Currently we're using 'new Date' which is less accurate for high accuracy
performance measures. On top of that, we are actually using performance.now()
in Navigation Timing to measure mediaWikiLoadEnd, and subsequently
relating it to mediaWikiLoadStart to produce mediaWikiLoadComplete.
Mixing Date and performance.now produces inaccurate results since the
two are usually not in sync. See T153819 for further details.
Solve this by moving the polyfil to startup.js instead.
Also add a basic unit test for mw.now().
Bug: T153819
Change-Id: Ib44538155aa9ba432ec4c58b09ead5333a3a942d
