Learning to see how its done to prep for client-side prolog. Some questions

[neenjaw]

This is sweet, really cool to see. A few questions for my learning and planning to take the prolog POC farther

1. In this line, the new Promise is constructed, but the first argument is named "reject", but this is still the resolve function, no? Have you renamed as per the intent, but functionally you are just returning the time out message?
   

   js-test-runner-clientside/src/index.ts

   Line 209 in 5ee2197

   return new Promise<TestRun>((reject) => {

2. the esm templated string is brilliant, and when you import that, it then becomes an imported module file rather than loaded in to the global space. 🤩 🥇

3. You have a webpack comment on 156, is this because webpacker will try to re-write this concern to bundle it?
   

   js-test-runner-clientside/src/index.ts

   Line 156 in 5ee2197

   const result = await import(/* webpackIgnore: true */ `${entry}`)

   Asking because I was planning to load the prolog wasm as it's bundled as its own package as well (https://www.npmjs.com/package/swipl-wasm) and its reasonably large (https://bundlephobia.com/package/swipl-wasm@5.0.11)

[SleeplessByte]

In this line, the new Promise is constructed, but the first argument is named "reject", but this is still the resolve function, no? Have you renamed as per the intent, but functionally you are just returning the time out message?

That was solved. It "accidentally worked", but it really should be (,reject) =>

You have a webpack comment on 156, is this because webpacker will try to re-write this concern to bundle it?

Yeah that's because I ported it from somewhere else. Normally webpacker will try to replace dynamic imports and here we don't want that! Exercism doesn't use webpack but esbuild, so this is fine. It's now gone, and re-organised. I am working on a workerized version if workers are available!

[SleeplessByte]

You'll be interested in this function:

js-test-runner-clientside/src/prepare.ts

Line 126 in 9c4609f

function makeDependencyGraph(code: {

It ensures the import replacements work correctly here:

js-test-runner-clientside/src/prepare.ts

Lines 100 to 110 in 9c4609f

	for (const filePath of dependencyOrder) {
	const code = user[filePath] ?? test[filePath] ?? shared[filePath];
	const importedCode = esm`${code}`;
	urls.push(importedCode);
	if (filePath in test) {
	entry = importedCode;
	}
	replaceImports({ from: filePath, to: importedCode }, user, test, shared);
	}

It does mean we don't support cyclic imports.

You may also like this trick which turns the tests into non-concurrent-async run:

js-test-runner-clientside/src/prepare.ts

Lines 360 to 366 in 9c4609f

	async function test(name, c) {
	run.current = run.current.then(() => {
	return promise(queueTest(name, c))
	})
	return run.current;
	}

It works because we always wait for the test to complete before leaving the describe block

js-test-runner-clientside/src/prepare.ts

Lines 386 to 387 in 9c4609f

	await run.current
	finishSuite()

...and that always waits until the last describe block is finished

js-test-runner-clientside/src/prepare.ts

Lines 330 to 340 in 9c4609f

	function finishSuite() {
	awaiting -= 1
	if (awaiting > 0) {
	return console.debug(\`[suite] still running, awaiting \${awaiting}\`)
	}
	run.result = run.failed === 0 ? 'passed' : 'failed'
	run.completed = true
	removeLogListener();
	}

That is all relying on this line:

js-test-runner-clientside/src/prepare.ts

Line 378 in 9c4609f

await c()

Given the following code:

describe(...)
describe(...)
describe(...)
describe(...)

Because it awaits a promise there, it gets to continue starting the describe blocks before the first test actually finishes.