Can we move this repo to a monorepo so we can more accurately test different usage scenarios?

[NullVoxPopuli]

In replying to: https://github.com/qunitjs/qunit/issues/1724 I was thinking about how to add a test to this repo such that we could simulate ESM node projects and ESM browser projects, and those style of projects are just different enough where it'd be easier if they had their own package.json, which works best in a monorepo.

what are the maintainers' thoughts on this?

thanks!!

[Krinkle]

QUnit is portable/isomorphic JavaScript directly usable in browsers, Node.js (plain), and other contexts. As such this "package" does require testing of both its CJS and (soon) ESM distro, and in both browser and Node.js enviornments.

The QUnit CLI for Node.js can and should be more cleanly separated indeed. While this package does contain both core and the CLI (and used by people for either/both purposes), the "npm" package I think makes sense to separate from the core release that we publish on the CDN.

I'm also working on a side project, a radically simple minimal dependency-free browser CLI, which I'd like to publish through the QUnit repo (i.e. to replace Karma Runner; competing somewhat with Testem, Airtap, TestCase, testee). It'd be good to clean stuff up a bit before committing that.

As a first step on the source, I'm thinking at least the following:

• /packages/qunit-core/
  • src/ what we have in /src today, sans CLI stuff. The current /src/core directory is a bit arbitrary and can probably folded and flattened into src.
  • test/
  • package.json - private, for building and testing core.
• /packages/qunit-node/
  • src/ what we have in /src/cli/ today mostly.
  • test/
  • package.json - public, the "qunit" npm package.
• /package.json - private, maybe using workspaces?

The "test" directory is where most of the mess exists today. We currently test Node.js support of core primarily via the CLI. We can keep using our own CLI to (also) run those same tests, but we should separate it from tests specifically about CLI code (which e.g. wouldn't pass if run standalone). And we could potentially expand the test matrix and actually run the majority of these also on standalone. Right now in Gruntfile#test-on-node we test only a small subset standalone.