We originally used 'templates' because it seemed like an obvious
choice for HTML files, and because 'packageFiles' requires extra code
to include anything that isn't a .js or .json file.
However, the templates are expected to be HTML fragments rather than
whole documents, and they are parsed in a particular way that takes a
lot of code to clean up (which we needed to do, because we use the
same test files for testing PHP code).
I tried doing it in the 'packageFiles' way, and the extra code doesn't
seem that bad in comparison after all. Moreover, the 'templates'
mechanism (when used the intended way) feels vaguely deprecated in
favor of Vue.js, and I'd rather move away from it.
This makes the tests faster too (probably mostly thanks to the removal
of the clean up code) – on my machine they go from 1800ms to 1500ms.
(Simplify linearWalk tests, as we no longer need to do weird things
with document fragments to get consistent outputs in PHP and JS.)
Change-Id: I39f9b994ce5636d70fea2e935a7c87c7d56dcb26
This fixes tests in modifier.test.js. The old parser tests
in parser.test.js are currently skipped.
Change-Id: If1fa8055b3cb6c6b43420ab40dd51af79fa083d9
Exposes that the old parser tests are asserting 0 comments added.
The tests are passing becaause testUtils.getThreadContainer returns
the empty string for both actual and expected.
Change-Id: I263a258a8db5c35a6fb1fc5ce281f902fc543038
Part of my secret plan to delete ApiParsoidTrait.
* Inject RevisionLookup into ApiVisualEditor
* Use RevisionLookup::getRevisionById instead of ApiParsoidTrait::getValidRevision
* Use RevisionLookup::getRevisionByTitle instead of ApiParsoidTrait::getLatestRevision
* Use standard MediaWiki error messages
Change-Id: I7244ee4916fb011fad5faa1d9f837e83f6ac2dc1
Follow-up to I8cf8b6960533718646189263acabc852ea976416, where the ...
was unintendedly removed.
Also switch to a suppression, because the type should be documented in
ParsoidClient, rather than enforced in callers. We will remove the
suppression once the documentation is updated.
Change-Id: I3ee2534959c8375d29f43e8391894f0a2002ae1c
The VisualEditorFeatureUsage instrument is a candidate for migration to
the Metrics Platform [0]. The first step of the migration is to log
events both using the Event Platform directly (i.e. via
mw.eventLog.submit()) and using the Metrics Platform client (i.e. via
mw.eventLog.dispatch()).
The Metrics Platform Client can mix in additional information -
so-called context attributes [1] - based on the stream configuration.
The majority of the default values mixed into each event via the
mw.eventLog.Schema defaults mechanism are already known to the Metrics
Platform Client.
Note well that the Metrics Platform client will not log an event without
one or more streams being configured to receive that event. Therefore,
this change is a NOP.
An example stream configuration is given in [2].
[0] https://wikitech.wikimedia.org/wiki/Metrics_Platform
[1] https://gerrit.wikimedia.org/g/mediawiki/libs/metrics-platform/+/aed6738b845/js/src/StreamConfig.d.ts#31
[2] https://phabricator.wikimedia.org/T309602#7973206
Bug: T309602
Change-Id: Ib919ae0e3f404c85cef17637ea91bb95d5030cf1
... for the sampling rate for the VisualEditorFeatureUse schema.
Bug: T312016
Depends-On: I259757db0c4441a3fcfce505d5bc82dcf2acf58c
Change-Id: I1c7f9c06384549deac2787f5df93c0078b6402af
* Fix estimate when using --current
* Add waitForReplication() after batches
* Add an option to restart from a specific point
* Remove TableCleanup, which doesn't work well for these use cases
* Use index on page_id when processing current revisions only
Bug: T315510
Change-Id: Idf9759743e67b3e116d6e20234b603bd76d4a41f
Consistent with core, most WMF extensions, and boilerplate as
documented in extensions/README and elsewhere; as per T316722.
Change-Id: I02cfcb2bd3debf877d1cbf8654dff4a98dd354ad
