recipes list (wiki)

[lorenzofox3]

• nodejs commonjs
• nodejs es
• nodejs typescript
• browser vanilla (webcomponents
• browser react
• browser vuejs
• browser svelte

[munrocket]

I have a solution to this list here nodejs/modules#47
-[x] nodejs ESM
-[x] nodejs CI
-[x] browser no bundling
-[x] browser with dev-server (puppeteer)

and
-[x] browser coverage

But I don't see any wiki page, that I can edit.

[lorenzofox3]

https://github.com/lorenzofox3/zora-recipes is the place where I started (a long time ago: the readme is not relevant anymore) and updated some time ago.

Note: there is actually now a test runner on top of zora for Nodejs which solves most of the problems.

And I am currently working on a testing solution for the browser

So far I am quite happy with both :)

[munrocket]

One idea for browser version tap consumer:

We can combine themes in browsers from qunit test framework and tap producing test runner for browsers without any bundle.

We just need to make a hook to console in browser and create div blocks with qunit semantics. I have a prototype in repo, but it’s far from complete solution. Main problem is to convert tap api to qunit template.

[lorenzofox3]

@munrocket In that case, it is probably easier to use directly the message stream from zora discarding any tap reporter: you see an example here

[munrocket]

I like zora because it with ES6, fast and works in browser and node. But I don’t understand why I need zora-dev-server since I have puppeteer or you not sold it to me. I see only wall of text, raw sources without pictures and online examples 🤓

But it is possible to run tests in browsers and tests will be literally same for node and browsers with puppeteer magic without any javascript bundlers. Look at this real example: https://munrocket.github.io/gl-bench/test/unit-test.html
You can check it in online and travis/circle-ci runs it for me for every commit and make coverage. No-one library in the world can do that without bundlers, only zora. Write once - runs everywhere.

Only one problem here: it looks like console output. If somebody will create new TAP consumer for browsers which one connect rich QUnit themes world and TAP producing test frameworks, this will be ultimate solution.

Am I right or I miss something?

[lorenzofox3]

zora-dev-server is actually intended to be used with tools such puppeteer (at least for automation and continuous integration).

It is still a work in progress and I am not trying to sell it to you (yet). Hence the documentation is vastly incomplete.

You can definitely use zora, decide to serve your test files the way you want (from html, using karma, cdn(s), codpen, etc), bundle/compile if that is needed. That is what zora is made for: give you the chance to build you own testing experience based on your actual needs.

Why would one want to use zora dev server ?:

• Puppeteer only works for chromium based browser: you might want to run your tests in other real browsers or with other automation tools. Simple example: how do you know a package related to the DOM API does not break in FireFox ?
• You might want to quickly toggle a devtool to debug, or use workspace to directly modify the sources from the browser without launching puppeteer (in that regard your setup has already a file server).
• It is a test runner: it gives you the ability to run a particular test, a bunch of tests matching a glob, changing the reporter to something more appropriate for debugging, etc . Everything without you to have to modify your test files. The project you have linked to has only one test file, so it does not make much difference but imagine if it would have dozens and you would want to run only one or a subset, how would you do ? You would probably have to comment out part of the HTML, that is not very convenient.
• Another important problem (the most important probably) is the way dependencies are resolved. It is easy to point directly to the ESM module of a dependency in the node_modules folder or to a CDN. That's fine if you have only a few. But in practice or for a larger scale project it is a nightmare to maintain. That's why most of the people write their code sticking to the package.json contract and node resolution algorithm:

import foo from 'my-module'; //not an url, I don't care and do not want to care where it is in the filesystem

// do something

And the browser won't be able to run that file. So they use a bundler on top of it, which need to be configured, slow down the whole process, etc. zora-dev-server serve your files and resolve the dependencies' urls on the fly so you don't have that trouble.

Your solution is very good and I am very happy you use zora this way, but it would only work for simple projects.

zora-dev-server aims at solving problems and ease the development of larger projects

[hugomrdias]

added support for zora in https://github.com/hugomrdias/playwright-test

[lorenzofox3]

It looks very nice @hugomrdias. I'll check it out and maybe add it to the readme !

[nettybun]

Thanks for publishing a Node TS example for Zora! I liked zora/pta as a runner but wanted automatic reloading on file changes without spawning new processes. Also wanted avoid tsc and tsc in a watch loop since I use esbuild. Here's Zora working in pure TS with worker_threads as a way to clear ESM cache (nodejs/node#49442) https://github.com/heyheyhello/haptic/blob/b29fed314f8826fe6221784bcfe970b5fdb2987b/test.ts

Wait a minute before testing it. This fix is being merged and published right now: antfu/esbuild-node-loader#3