Convert remainder of library to TypeScript, Vite build, include type checking in CI

[eyelidlessness]

Makes progress towards:

• Removing libxslt dependency
• Enabling client-side transformation

This PR:

• Converts everything to Typescript
• Removes doc generation (integration points are documented in README already)
• Switches build tooling to Vite
• Uses Vite with express adapter as node dev server

Original discussion of what to do about published docs

Branched from enketo/enketo-express#157. Here is a full diff, but it's probably more useful to view it after most of the file renames. I don't think there's much that needs much explanation, nor much that could be controversial here besides Typescript itself, and...

... docs

Aside from the obvious change, there's one thing I've left for discussion, which I honestly did not anticipate being such a blocker in this process: docs. I've currently commented out the build-docs command in CI, because it just plain doesn't work right now.

The jsdoc library can be made to "work" with TypeScript, for values of "work" ranging from "very poorly" (i.e. none of the types are included in API documentation) to "I can invest more time for unknown quality" (i.e. there is tooling which can convert the types back to JSDoc, but I don't know how well it works and I'd need to wrap it in a custom jsdoc plugin). Searching for jsdoc solutions is also very... not great, because the library shares its name with JSDoc, the comment documentation spec we've been using until now, and the library is even maintained in a monorepo alongside that spec and other related stuff.

I believe the most popular ~equivalent for TypeScript is typedoc. I took some more time to look into it, and while it's an impressive project, it comes with some caveats:

• The ecosystem seems to be both stagnant and fractured. I discovered this because I didn't especially like the default theme's low contrast, and wanted to find one more like the one we currently use. There are viable options, but many of them have been adapted to breaking changes introduced over a year ago. Thankfully, it's easy to add custom styles and tweak it to increase contrast and even be more like the existing styles, however.

• The breaking changes in question are technically semver-valid... with 0.x versioning. While Transformer's docgen requirements are relatively light (and I'll add below that they maybe should be lighter still), I'm concerned that this could be an issue for eventually converting other Enketo projects.

Options

• The null option: For Transformer alone, I think there's a much simpler no-tooling solution: the intended public interface is (I believe) just transform and escapeURLPath (which is presently only exported as an implementation detail for Express). They're documented directly with types and JSDoc, and transform is more thoroughly documented in README.md. The currently generated docs expose a great deal of package-private stuff that really isn't valuable to users, and some of it quite obviously wrong. I always like a "do nothing" choice in discussions like this, even if I think it's completely unviable. In this case, I think it's the best option for Transformer... but maybe not for preparing for converting anything else in Enketo to TypeScript.

• Make jsdoc happen: As discussed above, I don't know how much work would be involved nor how fruitful it would be. It would also continue producing not very valuable docs.

• Make typedoc happen: This is probably more viable. I made good progress, the biggest open question to me is how well it'll support the documentation needs of other projects. This feels like it would warrant a spike, and probably a separate PR.

• Some other tooling: 🤷‍♂️

• Minimally greater than null:

  1. the types and JSDoc are documentation across Enketo projects. They're very consumable in IDEs, and increasingly consumable in GitHub.
  2. The manual docs in Core/Express are written in Markdown and render quite well in GitHub as well (better, IMO, than on the various docs sites as currently deployed).

  This does seem viable too. It's just a big change.

[lognaturel]

I've marked this as draft pending merge of enketo/enketo#1137 and resolution of questions brought up in PR description.

The currently generated docs expose a great deal of package-private stuff that really isn't valuable to users

This feels similar to EE and I think it would be an improvement to stop publishing those docs (similar to enketo/enketo#988). I'm in favor of the "null option".

I think Core is the one component that does benefit from web-available JS API docs (as opposed to just in source). But we can decide what to do about that when we get there.

I'm in favor of removing all things around doc publishing as part of this PR.

some of it quite obviously wrong

This alarmed me so I asked @eyelidlessness about it. Since a lot of the comments have incomplete or no types, the resulting docs end up being misleading or incomplete (e.g. type object all over the place).

[lognaturel]

I think docs can be entirely removed here (docs dir and link from readme). Done

It all looks good to me. I've verified that what's documented in the README still works. I'm going to let this simmer and plan to do another sanity check and merge on Monday if there are no other comments.

[lognaturel]

The Github action needs to be updated to not build docs. I think we'll use the Github console to disable the Github.io site after that, right?

Is "Debugging test watch mode in VSCode" still up to date?

[lognaturel]

Agreed this is weird.

[lognaturel]

The Github action needs to be updated to not build docs

Just kidding, I was looking for it in the latest commits but it's done at 874b4b8

Mistakes were made

[lognaturel]

I went through commit by commit quickly trying to verify functional parity.