CommonAliases test suite: constructor aliases (HoldMyTask/QueueManager/TaskProcessor) are actually async factory functions

[Shinrai]

Summary

tests/CommonAliases.test.vitest.mjs (formerly CommonAliases.vest.mjs) fails 35/36 tests. Reproduced with a bare vitest run (no custom harness, no special env), so this is unrelated to the v4 CI onboarding / vitest-runner wiring in progress on ci/modernize-v4-workflows — pre-existing on next/master.

Root cause

index.mjs exports these as named-export aliases:

export { createHoldMyTask as HoldMyTask };
export { createQueue as QueueManager };
export { createTaskProcessor as TaskProcessor };
// (createHoldMyTask is also the default export)

But createHoldMyTask, createQueue, and createTaskProcessor in src/hold-my-task.mjs are declared as async function, not classes — they are factory functions, not constructors.

The test suite calls them as constructors:

const { QueueManager } = await import("../index.mjs");
const instance = new QueueManager(); // TypeError: QueueManager is not a constructor

Failing cases

All in the "Import Aliases" and "Control Method Aliases" describe blocks: HoldMyTask, queue/Queue aliases used with new, TaskManager, TaskQueue, QueueManager, TaskProcessor, the default export, star-import, and shutdown() (an alias test that also does new HoldMyTask()).

Reproduction

npx vitest run --config .configs/vitest.config.mjs tests/CommonAliases.test.vitest.mjs

35 failed / 1 passed.

Likely fix directions (needs a maintainer decision, not included here)

• Either the aliases should point at real constructors (if HoldMyTask etc. are meant to be classable), or
• the test suite's expectation is wrong and should call the aliases as async factory functions (await QueueManager()) instead of new QueueManager().

Filed as part of the v4 CI/release workflow onboarding (branch ci/modernize-v4-workflows) — out of scope for that PR per its own instructions (pre-existing test/source issue, not a CI wiring problem).

[cldmv-bot]

Closed in v2.0.0 — resolved by #11.