[RFC] modernize tests toolchain

The current test infra has some limitations:

• Requires build of the tests and source code
• No watch mode
• no sourcemaps
  • inaccurate coverage?
• Due to all of that, debug is cumbersome
• uses mocha 😉

a quick win for most of these problems would be to use ts-node/register

"test": "TS_NODE_PROJECT=test/tsconfig.json node -r ts-node/register ./node_modules/.bin/mocha test/*.ts --watch-extensions ts",
"test-debug": "TS_NODE_PROJECT=test/tsconfig.json node -r ts-node/register --inspect-brk ./node_modules/.bin/mocha test/*.ts",

Can be done also via mocha.opts

Action item for me: Make a draft pr for at least one package with the proposed change, to see if we want to go on with that

Additionally: ts3.7 should make it easier to setup project references for zero-build tests (not even the libs the tested code is importing)

For the long run, i think jest is a superior tests infra, but if and how needs can be discussed later

[earthlyreason]

Have been super busy myself @postspectacular but just wanted to chime in with unwavering support for UMD. I could not use this project without it (and it was very encouraging to see UMD support added almost immediately after I found it). I don’t use Webpack & co, and I don’t see them as solution to modules but rather a reframing of the whole system around themselves in order (in part) to avoid having an actual module loader, which AMD/require is. AMD loaders are really simple to implement, and they reflect the reality that modules are functions of their dependencies. They are a userland solution to a userland problem, and as such are tremendously flexible to do interesting things with.

Okay, I know this isn’t about tests, and yes, I’ll stop hijacking other people’s tickets! (But also thanks for the riff on spec… I appreciate that context & will follow up appropriately.)

[postspectacular]

@Bnaya Thank you again & Yeah, I’m sorry I did this in the spur of the moment. First tried it with one of the new packages and it worked great, then quickly applied it across the board. The only issue i had was w/ thi.ng/pointfree-lang, which uses an additional build step (PegJS) to generate its parser, so that one I left at the old setup…

As for your jest comment, let’s deal with this separately, since this is potentially going to be a hefty effort and I really can’t prioritize this in the near future (already spending too much of my little time on refactoring the docs). Is jest really going to make testing that much easier? I know close to nothing about it, but always happy to take advice from those in the know 😃