From these, we could potentially build a solution that estimates whether the suggestion count would be greater than zero. However careful discussion would be needed about how to trade off various considerations:

TLDR: Existing APIs can get us some data; but the heuristic nature of the matches can only give us an approximate guess that suggestions would actually be shown in a VisualEditor session. Additionally, performance implications would need to be considered very carefully.

@VCioffi-WMF boldly assigning this to you for QA. Let me know if I can help!

Verified: this is now operational on ruwiki

Sample output. It shows mwReference nodes and link/mwInternal annotations loading correctly, and an EditCheckAction being appropriately produced. The module list [ 'ext.visualEditor.editCheck.checks', 'ext.cite.visualEditor' ] was given. All implied dependencies were loaded automatically, as was editcheck/modules/config.json.

We can close the spike as complete, because we have now tested the biggest unknowns about running the Edit Check platform and its dependencies under nodejs, and it is clearly feasible.

Here is our proof of concept: https://gitlab.wikimedia.org/divec/editcheck-node . It takes standard client-side VisualEditor and Edit Check code served from enwiki and runs it in nodejs. It uses domino as the DOM implementation.

Based on internal discussions, here is a viable-sounding proposed architecture outline:

• Calculate a "default" suggestion count (intended for logged-out users) once per page revision (at article save time or otherwise). This would be a single number, e.g. 22.
• Serve that default count alongside the page fetch in all cases (included with the page content or otherwise).
• For a logged-out user, display that default count.
• For a logged-in user, make a separate (but lightweight) API call to determine the appropriate suggestion count for that user. Use client-side Javascript to update the display.

Created T434591 to represent more specifically the work I'm doing related to this.

See also T423465

Some benchmarking notes pulled through from gerrit and other conversations:

• This was benchmarked on an entry-level Android and a long-ish article (20k), running 100 simple regex rules.
• In the prior state, with no memoization, each full-article check run took around 8 sec.
• With the optimizations, it takes around 3 sec to check the whole article, and then about 50ms to do subsequent runs when editing a moderate-length paragraph.

One thing to consider: how important is it that a check produces identical results on different platforms (e.g. inside VE vs outside)? If identical results is very important, that would make porting far more of a challenge.

Done by me

Done by me

Done by me

Done by me

Done by me

Re-reviewed by me, after the candidate supplemented their submission at our invitation.

Done by me

The Current experience sections seem broadly aligned with what's happening in practice. However the labels Logged in with 0 edits / Logged in with > 1 edits could be made more precise:

• The experience labelled Logged in with 0 edits is what the user sees if they have never started editing before.
• The experience labelled Logged in with > 1 edits is what the user sees if they have ever started editing before.

Ohh good point ... is that subset likely to be cleanly separable?

Done by me

Done by me

done by me