Right now most of our checks work inside VE, and so surfacing these outside VE is dependent on Headless VE (T428811).
TextMatch is plaintext based, and is tailorable by communities to perform different classes of checks. So, it's likely to be both comparatively easy to make independent of VE, and comparatively fruitful in enabling many checks.
Note that the exact text searched for is very specific to the VE model, because it won't search within non-text things inside VE, and what HTML has become non-text is something we'd have to work out. (See also the whole unicode object replacement character being used to replace things inside the search, etc.)
Also, note that tickets like T422431 are going to make the logic notably more fiddly than just "find this text string in the HTML".
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.
How much of 'VE data model' or 'edit check logic' can be extracted out of the browser and into callable JavaScript functions/libraries? Instead of duplicating code, could a common JS library be used both server side and in a browser?
@dchan Not sure that we care if it's identical, but if the count-of-edits differs between platforms at all regularly that's going to be problematic for us. The situation we really want to avoid is telling someone there's a suggestion available and then not having one to show them when they start editing, after all.
@Ottomata technically so long as we're in a context where there's a DOM available, we can spin up the current VE data model from an HTML string, and just not instantiate the UI layers. In practice, we have very rarely tested this, so there might be problems. This is also more complicated than it sounds, because a lot of "what should actually be loaded?" requires knowledge from mediawiki -- various other extensions implement things like citations, templatedata, etc, and there mediawiki config (both LocalSettings and on-wiki JSON) that controls how various things behave. At a minimum, something that's a functional shim for mw.Api would be required. (It's this dependency on the general MW environment that made the headless-browser approach appealing, as you might imagine.)
I'm realizing I should have asked my question on T431602 as it is more general. I'm going to quote you there and ask another q! :) TY!