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
This was here from a year ago when we added CHROMIUM_FLAGS, which
has since rolled out.
Also make the assert-mw-env less fragile by checking the
env variables in one place each instead of two places. Before this,
it was relatively easy to accidentally add a warning for one, without
the shell exit code changing.
Change-Id: I6b85483981b415fe251b3760d5f282433e7fc4e9
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
Trying to get away with returning a single code and parameter-list that
was supposed to represent both human-readable and machine-readable data
was a mistake.
This patch converts it to use DataMessageValue, which represents the two
separately and also provides guidance for supplying translations of all
the error codes.
This also eliminates the "describeSettings()" method that was trying to
serve multiple use cases (in terms of the Action API, action=paraminfo
and action=help). It's replaced by two methods that each serve one of
the use cases. Also some of the functionality was moved out of the
TypeDef base class into ParamValidator, to better match where the
constants themselves live.
Also I wound up creating a NumericDef base class so FloatDef can share
the same range-checking logic that IntegerDef has. I probably should
have done that as a separate patch, but untangling it now would be too
much work.
Bug: T235801
Change-Id: Iea6d4a1d05bb4b92d60415b0f03ff9d3dc99a80b
Follows-up fa63a70ae9 which enabled this for CI to investigate
a Jenkins-specific issue, but it makes for a very noisy and visually
unpleasant local experience because these Karma lines interweave
with the structural output from the qunit/karma reporter.
With this change applied, the local experience from 'npm run qunit'
has clean output again like so:
```
…
mediawiki.storage
✔ set/get(Object) with storage support
✔ set/get(Object) with storage methods disabled
✔ set/get(Object) with storage object disabled
mediawiki.template
✔ add
✔ compile
✔ get
Finished in 13 secs
SUMMARY:
✔ 440 tests completed
```
Change-Id: I21555468ed30ca3a2220eba1d8a78cc140a13399
Also:
* Remove "watch" task from Gruntfile.
This wasn't exposed via npm-run and afaik rarely if ever used.
It seems mostly obsoleted by modern editors which perform
linting and style guidance as-you-type and on-save.
* Remove "chromium" target from karma config, the default
target supports both Chromium and Chrome.
* Remove unused "default" alias in Gruntfile. Was only
accessible if developers installed grunt-cli globally, which
we don't require and shouldn't encourage. The new minify task
is now exposed as "npm run build".
* Remove "test" alias in Gruntfile. Was only used by "npm run test",
which now uses "grunt lint" directly, which makes it more clear
that these are only linters, and not unit tests.
This references T211784 because ensuring no headed browsers are used
(which would need Xvfb to start), is a prerequisite for the new Node 10
images. We may still need to provide a slower Xvfb-wrapped variant for
some repos, but would be nice of mw-core wasn't one of them.
Bug: T211784
Change-Id: I270a16d2b4f799ac7c9f84e9e2ee23806bdbc57e
Adding 'grunt-svgmin' package and corresponding 'svgmin' task and
also crush SVGs. Several of them are featuring bad UX and are not optimal
in many different angles (a.o. clarity, universality, recognizablity etc.).
Specifically the 'mediawiki.skinning' ones.
But while they are here, let's make them suck less.
Change-Id: I8191ceac14565ae31d941982fab1586fa9b6bbdd
This is an internal script automatically loaded by Skin.php to
activate the 'jquery.hidpi' polyfill for all images on the current
page in browsers that don't natively support the 'srcset' attribute
on the HTML img element.
This script is loaded via ResourceLoader for which Grade A currently
requires:
> IE11+/Edge, Chr 65+, Ff 52+, Saf 5+, Op 15+, iOS 6+, Android 4+.
According to MDN and CanIUse, the basic 'x' syntax of srcset is supported, and
enabled by default, in:
> Edge, Chr 34+, Ff 38+, Saf 7+, Op 21+, iOS 8+, Android 5+.
This means in the following browsers, MediaWiki will no longer attempt to
replace images in articles with their hidpi versions.
| Browser | analytics.wikimedia.org (22 May - 22 June)
| ---------------------- | -----------------------
| IE 11 on Windows <= 7 | 3.4% (OS does not support HiDPI)
| IE 11 on Windows 8+ | 1.1%
| Safari 5 & 6 (desktop) | <0.1%
| Opera 15-20 (desktop) | <0.1%
| iOS 6 & 7 (mobile) | 0.1%
| Android 4 (mobile) | 0.5%
While the total of 1.7% is higher than our usual point where we decide
to remove support, I think we should consider dropping the hidpi polyfill
still for several reasons:
* MobileFrontend no longer uses 'srcset' attributes. As such, these browsers
don't actually change their behaviour based on the polyfill.
* For IE 11/Win8 in particular, most users don't have an HiDPI monitor,
but we still download the polyfill. HiDPI on Win8 is primarily tablets.
* In all cases where the polyfill activates, we download the HiDPI images
in addition to the standard resolution (which downloads and renders first).
This is because client-side JavaScript is not able to replace it sooner.
This could be considered a waste of bandwidth, as it can double or tripple
the bandwidth cost for end users.
This also means pages complete their loading much later because the browser
first renders the page nearly to completion with standard resolution images,
and only at the end our polyfill activates to restarts all image loading.
The experience gracefully falls back to normal web rendering, where the standard
resolution of the image is used. This would match what users of these devices
see on other websites, given client-side emulation of srcset is fairly rare.
== Modules
The 'mediawiki.hidpi' module was removed, and considered internal to Skin.php.
It contained no public methods. I confirmed there were no matches in Codesearch,
and no matches in mwgrep on Wikimedia wikis.
I did not remove 'jquery.hidpi', which is what contains the actual polyfill
and the jQuery.fn.hidpi() public method. (Codesearch shows 2 extenisons using
it, and mwgrep returned 1 unused gadget on Meta-Wiki referencing it).
It has been kept, but marked as deprecated. To be removed in a future release.
Bug: T127328
Change-Id: I42ce0feea1fbfe534f00e05a7cd8d81df0c33d8f
This was added in (r99923; 4d8c7e96ed) while reviewing the
'gadget-preferences' branch in SVN of the Gadgets extension during
development of MediaWiki 1.18, intended for use in a color picker
on Special:Gadgets as part of an experimental feature that was
never completed (r94051).
The module has no usage anywhere in Wikimedia Git, nor in any
third-party hosted repos indexed by MediaWiki Codesearch, nor
anywhere on-wiki at WMF in site scripts (per mwgrep).
Bug: T193826
Bug: T192623
Change-Id: I8ed6c09dc7efd750ad4688b895b2e3f808a0e52b
Single-file modules to src/, the remaining as sub directories.
A few highlights:
* mediawiki.Upload.BookletLayout. (stylesheet: no image references)
* mediawiki.feedback - Also move the image to its own images/ subdir.
* mediawiki.searchSuggest. (stylesheet: no image references)
* mediawiki.toc. (stylesheet: no image references)
Also updated any other references to 'src/mediawiki/' that I could find
in core:
* Fixed references in docs/uidesign/*.html
* Remove redundant exclude from jsduck.json.
After this, there are 4 files remaining in src/mediawiki,
which are the 4 files used by the actual 'mediawiki' base module.
Bug: T193826
Change-Id: I8058652892a78b3f5976397bd850741dd5c92427
Keep the main file in src/ for now, because it's got some whitespace
changes and a closure-wrap that make it differ from upstream's
version. Those changes are hard to review both for diffing and for
functional differences due to its odd-looking scope assignments that
I'd rather not change as part of this.
Change-Id: I248831cfa984432d0a30aa923a9bcd98029b05c4
Doesn't seem to add anything, except complexity.
This has the benefit of matching more closely the way the README
recommends running individual tests.
Also add a check for 'chromedriver' before running it.
Normally the -e and pipefail would suffice, but because
it runs in the background, the error can be buried,
hard to find, or even not cause exit code to be set
properly. Thus, do a simple 'hash' check that will
print a useful command and exit cleanly.
Before:
> $ something &
> [1] 57922
> -bash: something: command not found
> [1]+ Exit 127 something
> $ echo $?
> 0
After:
> $ hash something
> -bash: hash: something: not found
> (exit: 1) $ echo $?
> 1
Change-Id: Id95f18927b5443defe679a77a82c5cbdd127c716
Both Mocha and Cucumber tests should run. Since WebdriverIO supports only
running one test framework, the only way to do it is to have a generic
configuration file and two framework-specific files (Mocha, Cucumber). Having
Jenkins configuration file complicates things, and there is no need for
it.
Bug: T179190
Change-Id: I710066f7b5479dcad27aa57cd61007c1c2d88931
The 'karma:more' doesn't seem particularly useful, but the ability
to run Firefox from a preset seems more useful. Especially from CI
in Travis where one might want to use only one or the other.
Change-Id: I522295298888e8566781d81fa14dd08368bf0ce4
* Should have been part of,
I4488402686c8b9fefa0af5fed3c9a4b83cbff798
I95400637d1b85d2c607cd91bcb39ce21733295c8
Change-Id: I0546ba007d0a328504e359ade6a1e660387a0645
The progress reporter is quite nice to avoid spammy output to the
terminal, but it is not very human friendly when trying to find out what
is breaking.
Mocha has a very nice reporting organized as modules and list items for
each of the tests:
ext.cx.tools.template
✖ Equivalent template exists
✔ Adapting a template not existing in target language
✖ Adapting template having invalid title
✖ Template name and params adaptation using templatedata
✖ Template params adaptation using templateData - English to French
✖ Template params adaptation using templateData - English to Spanish
Add karma-mocha-reporter node module and make it the reporter.
Change-Id: Ic7d848b45e8e5ad3839d8a2bd822b63838319ad7
Introduce the WebdriverIO browser testing framework driven by Node.js.
The overall intents are:
* have MediaWiki core to provide a platform to run tests that is shared
between core and the extensions.
* phase out ruby driven browser tests eventually.
Code is namespaced in sub directory /tests/selenium
The 'pages' sub directory provides helper representing a MediaWiki page
such as Special:Login and human friendly helpers to interact with the
elements.
Add Grunt task webdriver:test.
Provide a npm script to easily spawn/dispose chromedriver and run above
grunt task.
wdio.conf.js provides all the configuration. It defaults to point to a
MediaWiki-Vagrant installation on http://127.0.0.1:8080. Can be
overriden with environment settings as needed.
glob patterns (specs) are made absolute paths from MediaWiki root path
that let us run the tests either from the root path (eg the npm
wrapper or from the tests/selenium directory when invoking wdio
directly. wdio assumes they are relative to the current working
directory, hence the normalization.
wdio.conf.jenkins.js extends the configuration and is used solely for
Jenkins. The switch is done from the Gruntfile.js whenever JENKINS_HOME
is set. Specially we want junit reports to be generated.
Provide a more specific eslint configuration.
References:
* MALU https://phabricator.wikimedia.org/source/malu/
* T151442 Research WebdriverIO
* T151443 Research Nightwatch.js
Bug: T139740
Signed-off-by: Antoine Musso <hashar@free.fr>
Change-Id: Ibe7a004a120e82af637ab3e31b725de743134c99
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
Enabling stylelint-config-wikimedia for Grunt stylelint,
which was already introduced in 3bf6f42929, but has not yet
been actively used to enforce Wikimedia CSS Coding Standards.
For this first patch nullifying several options, which will be enabled
in follow-up patches in order to be easier reviewable.
Change-Id: I3859e04797203a64d82206a379dbb320e5e113d5
Before karma-chrome-launcher 2.0.0, Chromium was only detected on Linux
and as part of the "Chrome" setting. "Chromium" is now recognised as a
separate browser and is detected on Mac and Windows as well.
https://github.com/karma-runner/karma-chrome-launcher/issues/45
Add a grunt target for Chromium so users may run the following to use
Chromium instead of Chrome:
grunt karma:chromium
Since we keep the default of "Chrome", we'll need an override for CI
since we install Chromium there instead of Chrome.
Depends on Ie9f906f8 being merged and Nodepool images updated.
Bug: T153756
Change-Id: I6ba0d971e7e8c3022d2ab6268ae637688189d768
By default the Karma proxy does requests against 'localhost', however
if the target wiki server has strict host validation (e.g. multiple
virtual hosts or otherwise strictly verified) then requests may fail
since load.php is not found. An example is with MW_SERVER=devwiki.local.
MediaWiki-Vagrant and Wikimedia CI are not affected since they use
'localhost' as the virtual host.
Set Karma proxy to change the hostname accordingly.
Reference:
https://github.com/karma-runner/karma/issues/1729https://github.com/karma-runner/karma/commit/ae05ea4
Bug: T153757
Change-Id: I317d5686aecd1fb6cf6921cdca77670cded85607
All A-graded browsers now supports JSON so skip the
JSON polyfill. Krinkle investigated the current
status for 3 months on Wikimedia traffic (T141344#2784065)
with support being nearly 100%.
Bug: T141344
Change-Id: I8280faf1cbcd876ead2dafae4347b7d46e3e2acb
Grunt's `**` matches symlinks but doesn't follow them, so `**/*.js`
matches files that `!extensions/**` doesn't see to exclude.
Bug: T151381
Change-Id: I5d8ae6e24f2fa09efc97db871b0c08d4fbc68efd
* Hex colours must be in short form where possible ('fff' not 'ffffff')
* Hex colours must be used over named colours ('fff' not 'white')
* Hex colours must be valid ('fff' not 'ffq')
Change-Id: I2ba04cc3ad9898c17fee3c65bb3bead834c3a1fd
Initially, with just a single rule to make this a smaller change that we can
incrementally extend up to the full Wikimedia coding conventions preset; namely,
forcing hex references to colours to be in lower-case.
Note the odd src definition to avoid referring to mediawiki.less the directory in
the glob.
Change-Id: I34f0c8e3c8280e3fce0aa22d7537100b850cbb8d
Disable disallowBlankTranslations, disallowDuplicateTranslations and
disallowUnusedTranslations for now as they fail so much.
Change-Id: I52e1555335a6e64b1e9db541ba726cf6ce8c7dd0
