If we could lint the HTML output of KS macros, we could make this whole class of problems less likely to happen. It would be great to do this once for all macros, but I’d be happy enough to have a test for each macro that linted the output explicitly. It seems like this would be doable if there was a package we could use in the KS test environment, but I don’t know of any.
Does this sound like a good idea? Does anyone have any good suggestions for tools we could use?
I think this is a pretty good idea. It would be nice if it could be automatically done as part of the commit process, sort of like how interactive examples go through an automated linting or testing cycle during the pre-commit stage.
The first step is to write an automated test for the Add-on sidebar. You can then later add a linting step for the test output, if you think it is still needed.
There’s also a grunt plugin, a gulp plugin, a python pip package, and a Docker file.
Alternatively, we could just use the HTTP (REST) API that Web-based instances of it expose — either using https://checker.html5.org/ or Ready to check - Nu Html Checker. (One downside of the Ready to check - Nu Html Checker instance is that does rate limiting; if it receives more than a certain number of request per minute from the same IP range, it temporarily blocks further requests from that IP range for some period of time.)
I was aware actually that the validator is yours, and I did consider asking you about it :). We can use npm modules in KumaScript tests, and it looks like there is an npm distribution of it (?) (https://www.npmjs.com/package/vnu-jar)
I’ll try to dig into this when I get some time, but will certainly ask for help if I get stuck :).
Yeah, that’s essentially just a distribution of the vnu.jar file with a convenience wrapper around it. To use it, it’d b necessary in your script to use exec(java -jar …) or such to run the jar, and write your own code for handling the output (or just send it to stdout/stderr).
