feat: support for multiple setups

[happybeing]

I'm setting uvu with puppeteer to run tests with call functions in the browser environment via a window.__API__ global.

For development I want a test:dev command which uses uvu to run the webpack-dev-middleware dev server programmatically. And I want a test:build command which creates a build and then runs a different server to serve the distribution directory, and run the same tests against that. I have this working.

So I'd like a way to run the same tests with slightly different setup. For now I'm creating a "config.js" in the tests directory and importing that into the setup script but it's a bit clunky so I wonder if this could be done via the uvu CLI. For example providing a flag to set a value which can be picked up in the setup script (e.g. --set variable=value where value could be JSON).

[lukeed]

Hey, you can use the -r,--require flag for this, if I understand what you're doing correctly.

That flag loads as uvu starts up. This can be a transform helper module, a file to modify process.env variables, etc

Does that cover your needs?

[happybeing]

I hadn't thought of that! That would be nicer than the solution I have working but I'm having trouble getting it to work. Possibly because I'm using ESM. My src/__tests__/ contains index.js and a package.json as follows. The index.js imports both '.js' (e.g. ./setup/pupeteer.js) and some a local .cjs modules to set up a web server in order to run tests via puppeteer.

{
  "private": true,
  "type": "module"
}

I ended up with this as a way of getting it all to work together. It works until I use --require somefile.cjs which seems to prevent uvu from being able to import the index.js:

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/user/src/gitportal/p2p-git-portal-wasi/src/__tests__/index.js
require() of ES modules is not supported.
require() of /home/user/src/gitportal/p2p-git-portal-wasi/src/__tests__/index.js from /home/user/src/gitportal/p2p-git-portal-wasi/node_modules/uvu/run/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename /home/user/src/gitportal/p2p-git-portal-wasi/src/__tests__/index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /home/user/src/gitportal/p2p-git-portal-wasi/src/__tests__/package.json.

    at new NodeError (node:internal/errors:277:15)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1119:13)
    at Module.load (node:internal/modules/cjs/loader:967:32)
    at Function.Module._load (node:internal/modules/cjs/loader:807:14)
    at Module.require (node:internal/modules/cjs/loader:991:19)
    at require (node:internal/modules/cjs/helpers:92:18)
    at /home/user/src/gitportal/p2p-git-portal-wasi/node_modules/uvu/run/index.js:9:3
    at Array.forEach (<anonymous>)
    at Object.exports.run (/home/user/src/gitportal/p2p-git-portal-wasi/node_modules/uvu/run/index.js:6:9)
    at /home/user/src/gitportal/p2p-git-portal-wasi/node_modules/uvu/bin.js:28:30
error Command failed with exit code 1.

I'm not really too worried about solving this issue as I have something working without --require and my setup might just be a bit unusual.

I have another issue now in that the test never exits. The tests are run and correctly show the results, but yarn uvu src/__tests__ -b -i setup never exits and I have to Ctrl-C. This may be because I'm index.js starts a couple of web servers in the same process (although I don't understand why). Unless there's a quick fix for that I'll open another issue. SOLVED: I needed to use http-shutdown to stop the servers and when they complete, call process.exit().

Thanks for your help!

[lukeed]

Closing this as I think things have been resolved, especially after #91

Please let me know if I've misunderstood. Thanks~

[happybeing]

I'm happy for this to be closed as I have a workaround (my original scheme of creating a config.js) but just to note: I couldn't get the --require solution working. I didn't put a lot of effort into it though.