WeBWorK: pretext-webwork.js for WeBWorK/PG 2.19

[Alex-Jordan]

This adds the pretext-webwork.js file for when the WW/PG version is 2.19.

Right now, webwork-dev.aimath.org is on version 2.19. (Note that I will try to leave this server stable and functioning, but now and then I may be changing/upgrading things there.) So what you can do is edit the sample chapter publication.xml file to use this WW server, and then build the sample chapter. Note, not with the CLI, since it does not yet have the commit in this PR. Then when you interact with the sample chapter output, you should see nice things. The main thing is how feedback (telling you if you are correct or not, and perhaps giving a more detailed feedback message) is delivered.

Once this is in, I will ask people with WW projects to build using webwork-dev.aimath.org, just to test.

Once this is also in the CLI, I will ask @bnmnetp to build the sample chapter for Runestone with webwork-dev.aimath.org, and try things out there as well.

[rbeezer]

In! Thanks.

While cleaning up stray whitespace, I noticed this uses tabs. They are now 4 spaces each.

Do the other WW/JS files use tabs?

[Alex-Jordan]

Thanks, I have a follow up with some small improvements to this file coming up.

Each of these:

js/pretext-webwork/2.16/pretext-webwork.js
js/pretext-webwork/2.17/pretext-webwork.js
js/pretext-webwork/2.18/pretext-webwork.js

have tabs in them. IIRC, tabs were originally outlawed in PTX XSL/XML because of some difficulties raised by their presence. I've grown to appreciate tabs over spaces in other projects, and I wondered if you would ever be open to revisit the tabs policy.

Related (but not necessarily overlapping) WeBWorK and PG have been applying a linter (enforced by GitHub) that imo has accelerated development. People can contribute code, and apply the linter before opening a PR, and it makes things easier for the reviewers. Would you be open to this here? It could start small, say only with CSS or JS files.

[rbeezer]

I wondered if you would ever be open to revisit the tabs policy

Doubtful. A tab is ill-defined visually. Case in point. Your tabs were 4 spaces in my editor, hten 6 spaces (I think) in git diff as I replaced them.

WeBWorK and PG have been applying a linter

I don't like linters, nor automatic applications of them, either. Nothing stopping a developer from using one routinely, though. so long as it does not get too bizarro.

[Alex-Jordan]

Your choice, of course. But:

nor automatic applications of them

is not what I mean. Just to explain what I mean: In the WW/PG repos we have linting scripts. You manually run them. If you forget, and open a PR with un-linted files, GitHub will run the linter too via a GH action. It will detect that your files are unlinted, and disallow merging. The PR author is alerted to this and must return to do the linting, and push/force-push back up. The important thing is the PR author is supposed to test linted code, not test unlinted code, push, and let GH do the linting.