feat: initial workerd:bundle support

[Copilot]

This PR implements working workerd:bundle support by solving the async scheduling incompatibility.

Problem Identified

The initial implementation appeared to work but had a critical flaw: tests were scheduled but never ran. Investigation revealed:

• The test runner schedules tests asynchronously using setTimeout(run, 0) in src/engine.pure.cjs
• Workerd's test framework doesn't process these timers during test execution
• Created an intentionally failing test that incorrectly passed, confirming tests weren't running
• Exit codes remained 0 even when assertions should have failed

Root Cause

Workerd expects synchronous execution within its test function, while the test runner uses asynchronous scheduling:

1. Test files are imported and tests are registered via describe() and test() calls
2. After test definitions, setTimeout(run, 0) schedules the actual test execution
3. In workerd, this timer callback never fires - the test function returns before timers execute
4. Result: Tests appear to pass but never actually run

Solution Implemented

Manual Test Execution: Instead of relying on setTimeout, explicitly trigger test execution from the workerd wrapper.

Key Changes

1. Test Execution Model (src/engine.pure.cjs)

• Skip automatic setTimeout scheduling for workerd platform
• Export run() function globally as EXODUS_TEST_RUN for workerd
• Call _maybeProcessExitCode() synchronously after tests complete (not via setTimeout)

2. Module Exports (src/engine.js, src/node.js)

• Export run function (available for workerd platform)
• Enables manual test triggering from workerd wrapper

3. Engine Configuration (bin/index.js)

• Added workerd:bundle engine definition
• Set workerd as browser-like for proper test lifecycle management
• Generate workerd Cap'n Proto config file
• Generate wrapper module that:
  • Imports the test bundle
  • Manually calls globalThis.EXODUS_TEST_RUN() to execute tests
  • Checks exit code after completion
  • Throws error if tests fail

4. Documentation

• Added workerd:bundle to README.md engines list
• Added test:workerd npm script to package.json

How It Works

1. Test files are imported, registering tests via describe() and test() calls
2. Unlike other engines, tests are NOT auto-scheduled with setTimeout
3. Workerd wrapper explicitly calls EXODUS_TEST_RUN() within the test handler
4. Tests execute and set exit code based on results
5. Wrapper checks exit code and throws if tests failed

Testing

✅ Passing tests correctly pass (tests/simple.test.js)
✅ Failing tests correctly fail with proper error messages
✅ Multiple test files work correctly
✅ Test output is properly displayed
✅ Linting passes

The implementation successfully works around workerd's setTimeout limitation by providing a manual execution path that integrates with workerd's test framework.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>workerd support</issue_title>
<issue_description>Can use the regular pure bundle path, but needs special handling to run the generated bundles

Test on simple.test.js at first</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes workerd support #52

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[ChALkeR]

Check that failing tests throw (by generating a temporary testcase failing on a purpose, but not commiting it)

It looks like no tests are actually executed

[Copilot]

Check that failing tests throw (by generating a temporary testcase failing on a purpose, but not commiting it)

It looks like no tests are actually executed

You're absolutely correct - tests are not actually executing in workerd.

I created a failing test and confirmed it incorrectly passes. The root cause is that the test runner schedules tests with setTimeout(run, 0) (in src/engine.pure.cjs:107), but workerd's test framework doesn't process those timers during test execution. The bundle imports successfully, tests are scheduled, but the scheduled run callback never executes.

Workerd expects synchronous execution within its test function, while the test runner uses asynchronous scheduling. This is a fundamental incompatibility that would require restructuring the test runner's execution model to support.

The workerd:bundle implementation should be removed or marked as not working until we can address the async scheduling issue.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• iojs.org
  • Triggering command: /usr/bin/curl curl -q --fail --compressed -L -s REDACTED -o - (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[ChALkeR]

@copilot fix it with an implementation that works asynchronously

[Copilot]

@copilot fix it with an implementation that works asynchronously

Fixed! Implemented working async execution for workerd.

Root cause: Workerd doesn't process setTimeout callbacks during test execution, so the test runner's setTimeout(run, 0) never fires.

Solution:

• Skip setTimeout scheduling for workerd
• Export run() function globally as EXODUS_TEST_RUN
• Workerd wrapper manually calls EXODUS_TEST_RUN() to execute tests
• After completion, check exit code and throw if tests failed

Testing:
✅ Passing tests work: tests/simple.test.js passes
✅ Failing tests properly fail with error messages
✅ Multiple files work correctly

Changes in commits e18a250, 9d0524c, and 0f02e75.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• iojs.org
  • Triggering command: /usr/bin/curl curl -q --fail --compressed -L -s REDACTED -o - (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[ChALkeR]

let's merge and then improve