Insights from dogfooding

[wojpawlik]

deno.ns/tools/run_deno_unit_tests.ts -> deno.ns/tools/deno_test.js -> @fromdeno/cache/node/dtest.mjs -> fdt

1. deno.ns doesn't use URL imports, so NODE_OPTIONS=--experimental-loader=ts-node/esm fdt worked great for testing TypeScript code, without explicit build step.
2. fdt uses dynamic import to load test files in order to support ESM, so modifying require.extensions via --require=ts-node/register or --require=sucrase/register/ts isn't supported.
3. API for registering tests can be required from CJS tho.
4. deno.ns first "test file" contains no tests. Instead, it sets globals required by subsequent tests and changes working directory. I expect this to be common pattern until I manage to isolate test files form each other in a major release.
5. @fromdeno/cache does use URL imports, so it uses deno2node to build the test files (into out/test/) alongside source (into out/src/). Tests on Node.js are ran after build, in preposterous "postprepare" script :)
6. I recommend https://deno.land/std/node/assert.ts to avoid having to vendor https imports for testing.
7. If you build src/ and test/ simultaneously, enable "composite". Otherwise, TypeScript may build src/ into out/ instead of out/src/ when you don't build tests, breaking your package.