The new mw eslint config comes with node 12 and the change will be
quite big due to the lock file. I wanted to keep the diff of actual
code changes seperate.
- Applied all code style recommendations
- Removed one test that's not giving any value
- Changed regex .match to .test for performance and convinience
Change-Id: I578be8c6460c7a4d1220354c028a9bfd9bb86d13
It's never used in another context but together with the
….Slider module.
Motivated by the confusion about the two types of require()
introduced in Idf1cc79.
Bug: T233279
Change-Id: I922d7ab56fd3ce80bc901f1a5d7174df6fe6756d
Each RL module comes with the cost of its name + hash being sent over every
request and in the startup module increasing the time to load the page.
Bug: T229791
Change-Id: I3ae230a84112a70ab369ffbff70e173b8f07ec1a
First I jumped on replacing both jscs and jshint with eslint but
it might be premature decision. Although linting with eslint
is possible (like in there is wikimedia config for eslint)
it is still not clear should it
But in case the change happens we will be ready.
Apart from config stuff this changes few bits spotted by eslint:
improves some indentation, removes weird spaces, completes some
doc blocks, changes IIFE forms in tests. These changes do not
seem controversial.
Change-Id: I9f8bf0f5745da8e662685f4cd879ea4baa609c01
Localized format of date containing month name, day, year and time
is used instead of format enforcing the order of time and date,
and use of short month name.
Bug: T141167
Change-Id: I39b2844e777beb986cefb3097d52d481bb038a63
This changes the previous behaviour of fetching always up to
500 most recent revisions.
Now the extensions fetches N revisions including the newer
revision selected to diff as the most recent revision.
N is number of revisions that would fit in the current
window when rendered as bars.
When user is close to either "end" of the slider, extensions
fetches another batch of up to N older or newer revisions,
as long as user does not reach the oldest or the newest
revision of the page.
Among others, this removes the limitations of the previous
approach: showing only 500 revisions, and failing to show
anything when any of selected revisions was older than
500 recent revisions.
This change also simplifies usage of Api class.
Bug: T135005
Change-Id: Ib3f4a6ac57ff17008f9d8784c4716bd294443096
After fetching a batch of revision data, user names are extracted
and another API query is made to get gender preferences for users.
This change also moves a code responsible for MediaWiki API calls
to its own class.
Bug: T136367
Change-Id: Id11fe14e9ca37829141ae92b13b51f10f992eb96
There seems to be no good way to enforce language on the QUnit tests. It works
for the number formatting by setting the user language on the fly but for everything
else it fails. I simplified some tests and skip some tests or asserts when the language
is not 'en'.
I also added a helper to have conditions for skipping tests. This should be part of
QUnit IMO.
Still I dont know if this is something we should care about at all or just assume, that
devs will know what they do when they try to run tests.
Change-Id: I624ccf3984434e06200abffe7ccdd25b396251af
