Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
NullVoxPopuli opened this issue Oct 14, 2023 · 1 comment
Labels
Type: Meta Seek input from maintainers and contributors.
Milestone

Comments

@NullVoxPopuli
Copy link
Contributor

In replying to: #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 Krinkle added the Type: Meta Seek input from maintainers and contributors. label Jun 20, 2024
@Krinkle Krinkle added this to the 3.0 release milestone Jun 20, 2024
@Krinkle
Copy link
Member

Krinkle commented Jun 20, 2024

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.

@Krinkle Krinkle modified the milestones: 3.0 release, 3.x release Jun 20, 2024
Krinkle added a commit that referenced this issue Jun 23, 2024
This produces strings (HTML) and is available unconditionally.
It does not depend on the DOM.

Pluck its test out of /test/reporter-html/ and add it to /test/main
instead. Thus coverering it in Node.js, mozjs, web worker,
and CLI as well.

Ref #1726.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Meta Seek input from maintainers and contributors.
Development

No branches or pull requests

2 participants