fix: three jsval-representation gaps in checked-dynamic lowering

.github/workflows/msvc-verify.yml

@@ -0,0 +1,65 @@
+name: MSVC POSIX Shims
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  msvc_compile:
+    name: verify MSVC compilation
+    runs-on: windows-latest
+    timeout-minutes: 15
+    steps:
+      - uses: actions/checkout@v4
+      - uses: pnpm/action-setup@v4
+        with:
+          version: 11
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: .node-version
+          cache: pnpm
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm build
+      - name: Compile runtime with MSVC clang
+        shell: pwsh
+        run: |
+          # Verify clang is MSVC-targeted (not mingw)
+          clang --version
+          # Compile a simple program — this is the exact scenario from #25
+          node packages/cli/dist/main.js run tests/corpus/001-hello.ts --backend c
+      - name: Compile Map + sort program (the bare.ts pattern)
+        shell: pwsh
+        run: |
+          $ts = @'
+          const m = new Map<number, number>();
+          m.set(1, 10);
+          m.set(2, 5);
+          m.set(3, 20);
+          const sorted = [...m.entries()].sort((a, b) => a[1] - b[1]);
+          console.log(sorted[0][0], sorted[0][1]);
+          '@
+          $ts | Out-File -Encoding utf8 test-msvc.ts
+          node packages/cli/dist/main.js run test-msvc.ts --backend c
+
+  linux_regression:
+    name: verify no Linux regressions
+    runs-on: ubuntu-24.04
+    timeout-minutes: 10
+    env:
+      SCRIPTC_NO_CACHE: "1"
+    steps:
+      - uses: actions/checkout@v4
+      - uses: pnpm/action-setup@v4
+        with:
+          version: 11
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: .node-version
+          cache: pnpm
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm build
+      - name: Corpus smoke tests
+        run: >-
+          SCRIPTC_TEST_WORKERS=4 pnpm exec vitest run tests/harness/differential.test.ts
+          -t "001-hello|518-array-sort|520-map-basics|path"

CHANGELOG.md

@@ -4,6 +4,10 @@ All notable changes to scriptc will be documented in this file.
 
 ## Unreleased
 
+### Features
+
+- **Native MIDI messaging.** `node:midi` (API-compatible with node-midi/@julusian/midi) enumerates ports, opens inputs and outputs including virtual ports, sends raw messages, and receives time-stamped messages through the `"message"` event on the dependency-free event loop. Backends bind each platform's MIDI stack — ALSA on Linux, CoreMIDI on macOS, WinMM on Windows — and are linked only into binaries that use the surface. An open input holds the loop alive like a bound `dgram` socket; the runtime is byte-transparent and does not parse MIDI semantics. `openVirtualPort` is POSIX-only (WinMM has no user-space virtual ports), and any MIDI surface on `wasm32-wasi` refuses before linking with `SC3002`.
+
 <!-- release:start -->
 
 ## 0.0.35

docs/src/app/how-it-works/page.mdx

@@ -31,7 +31,7 @@ fib.ir.json
 
 - **Memory** — values are reference-counted; an acyclic value is freed the moment its last reference drops. Reference cycles are collected at deterministic points by a cycle collector, not a concurrent GC. There are no GC pauses and no tracing heap.
 - **Concurrency** — `async`/`await` runs on stackful fibers with JS-exact scheduling: microtasks drain in the same order Node's do, timers fire in the same order, and the event loop (kqueue on macOS, epoll on Linux) has no external dependencies.
-- **The server stack** — `net`, `http`, `https`, `tls` (vendored mbedTLS), `dgram`, `dns` are native implementations on that same loop.
+- **The server stack** — `net`, `http`, `https`, `tls` (vendored mbedTLS), `dgram`, `dns` are native implementations on that same loop, as is `midi` (ALSA/CoreMIDI/WinMM, linked only into binaries that use it).
 - **Numbers** — JS-exact f64 semantics, including shortest-roundtrip number-to-string formatting fuzz-verified against Node's output.
 - **Regular expressions** — the same ECMAScript-exact bytecode interpreter QuickJS uses, linked only into regex-using binaries.
 

docs/src/app/introduction/page.mdx

@@ -51,7 +51,7 @@ The static surface covers the language and the standard library real programs us
 
 - **The language** — classes with single inheritance and dynamic dispatch, closures with JS capture semantics, generic function declarations (monomorphized), discriminated unions driven by TypeScript's own narrowing, `async`/`await` with JS-exact scheduling, exceptions with `finally`, destructuring, spread, optional/default/rest parameters, getters and setters, iterators, template literals, bitwise operators with JS-exact ToInt32 semantics, and the static slice of regular expressions.
 - **The standard library** — strings with UTF-16-exact surface semantics, arrays, `Map` and `Set` with JS-exact ordering, read-only `Date` values and calendar getters, `JSON` with runtime-validated casts, `Math`, typed arrays and `Buffer`, `Error` hierarchies with typed `catch`.
-- **Node's API surface** — `fs` (sync and promises), `path`, `process`, `child_process`, `os`, `crypto`, `url`/`URL`, `zlib`, timers and signal handlers on a dependency-free event loop, and the server stack: `net`, `http`, `https`, `tls`, `dgram`, `dns`, `readline`. Real servers compile:
+- **Node's API surface** — `fs` (sync and promises), `path`, `process`, `child_process`, `os`, `crypto`, `url`/`URL`, `zlib`, timers and signal handlers on a dependency-free event loop, the server stack: `net`, `http`, `https`, `tls`, `dgram`, `dns`, `readline`, and native `midi` (raw MIDI messaging over the same loop). Real servers compile:
 
 ```ts:server.ts
 import { createServer } from "node:http";

docs/src/app/limitations/page.mdx

@@ -89,6 +89,16 @@ const who = process.argv.length > 2 ? process.argv[2] : "world";
 
 The production <code>wasm32-wasi</code> target supports the complete executable language tier through LLVM: async/await, promises, generators, timers and other portable event-loop work, stdin/readline, filesystem callbacks and promises, and the <code>--dynamic</code> island. Portable WASI Preview 1 has no socket, process-spawn, OS-signal, network-interface, or filesystem-notification capabilities, so networking/fetch, child processes, signal APIs, <code>os.networkInterfaces()</code>, and <code>fs.watch</code> are rejected before linking with <code>SC3002</code>. <code>--sanitize</code>, native FFI, and library-mode archive builds are also unavailable. Filesystem access is bounded by the host's preopens; <code>scriptc run</code> exposes the current working directory and <code>/tmp</code>. See [Platform Support](/platforms) for build and run details.
 
+## MIDI limits
+
+`node:midi` is raw MIDI messaging, modeled on node-midi/@julusian/midi — enumerate ports, open input/output (including virtual ports), send raw messages, and receive time-stamped messages via the `"message"` event.
+
+- **The runtime is byte-transparent.** It carries raw message bytes (Note On/Off, CC, Program Change, Pitch Bend, SysEx as a byte run) and neither parses nor validates MIDI semantics. Higher-level semantic events (`noteon`, `cc`, …), MIDI file parsing, sequencing/clock scheduling, and MIDI 2.0 / UMP are out of scope.
+- **Virtual ports are POSIX-only.** `openVirtualPort` works on Linux (ALSA) and macOS (CoreMIDI); on Windows WinMM it fails at runtime with a clear error, because WinMM has no user-space virtual ports. See [Platform Support](/platforms).
+- **No MIDI on WASI.** WASI Preview 1 has no MIDI capability, so any `node:midi` surface is rejected before linking with `SC3002`. Browser Web MIDI is a separate runtime the WASI target does not cover.
+- **`on`/`once` accept only the `"message"` event**, with a `(deltaTime, message)` listener. `deltaTime` is seconds since the previous message on that input (`0` for the first) and is inherently nondeterministic — a differential test must never print it.
+- **A Linux host without ALSA** (many CI containers) has no MIDI backend: the runtime enumerates zero ports and throws on open. The hardware-free loopback tests use a virtual-port pair on a capable host.
+
 ## Tooling gaps
 
 - `scriptc run` does not forward extra CLI arguments to the program — `build` and invoke the binary directly.

docs/src/app/platforms/page.mdx

@@ -63,6 +63,44 @@ WASI is a production LLVM target with the same language tiers as the native targ
 
 The remaining executable boundary is host capability, not language coverage. WASI Preview 1 has no portable socket, process-spawn, OS-signal, network-interface, or filesystem-notification APIs. Networking/fetch, child processes, signal APIs, <code>os.networkInterfaces()</code>, and <code>fs.watch</code> therefore fail before linking with diagnostic <code>SC3002</code>. <code>--sanitize</code>, native FFI, and library-mode archive builds are unavailable too. Filesystem behavior is bounded by the host's preopens, and process/OS introspection follows WASI's reduced model.
 
+## MIDI (`node:midi`)
+
+Raw MIDI messaging (`node:midi`, API-compatible with node-midi/@julusian/midi) is a native runtime unit linked only into binaries that use it. Each platform binds its own MIDI stack, so the availability is per target:
+
+<table>
+  <thead>
+    <tr>
+      <th>Platform</th>
+      <th>Backend</th>
+      <th>Virtual ports</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>Linux</td>
+      <td>ALSA sequencer (<code>libasound</code>, linked as <code>-lasound</code>)</td>
+      <td>Yes — a native ALSA port other clients connect to</td>
+    </tr>
+    <tr>
+      <td>macOS</td>
+      <td>CoreMIDI (<code>-framework CoreMIDI</code>)</td>
+      <td>Yes — <code>MIDISourceCreate</code>/<code>MIDIDestinationCreate</code></td>
+    </tr>
+    <tr>
+      <td>Windows</td>
+      <td>WinMM (<code>winmm.lib</code>)</td>
+      <td>No — WinMM has no user-space virtual ports; <code>openVirtualPort</code> fails at runtime with a clear error</td>
+    </tr>
+    <tr>
+      <td>WASI</td>
+      <td>None</td>
+      <td>No — any midi surface fences before linking with <code>SC3002</code></td>
+    </tr>
+  </tbody>
+</table>
+
+An open Input is a live pollable source that holds the event loop alive (like a bound `dgram` socket); an Output is fire-and-forget. Port enumeration (`getPortCount`/`getPortName`) works on a fresh handle before `openPort`. The runtime is byte-transparent — it neither parses nor validates MIDI message semantics. Note that a Linux host without an ALSA sound stack (many CI containers) enumerates zero ports and throws on open.
+
 ## Cross-target limits
 
 - `--sanitize` is a host-build lane.

package.json

@@ -20,6 +20,7 @@
   "devDependencies": {
     "@types/node": "^24.0.0",
     "eslint": "^9.20.0",
+    "midi": "npm:@julusian/midi@^3.8.1",
     "tsx": "^4.19.0",
     "typescript": "5.9.3",
     "typescript-eslint": "^8.24.0",

packages/compiler/ambient/scriptc-node-fallback.d.ts

@@ -3032,6 +3032,47 @@ declare module "node:dns" {
   export * from "dns";
 }
 
+/* node:midi — raw MIDI messaging over the event loop (scr_midi.c, linked
+ * only into using binaries — the moduleUsesMidi switch). API-compatible
+ * with node-midi/@julusian/midi so the Node differential baseline is a
+ * real, installable package. Input is a live pollable source (an open
+ * port holds the loop alive, like a bound dgram socket); Output is
+ * fire-and-forget (send never holds the loop). Port enumeration
+ * (getPortCount/getPortName) works on a fresh handle before openPort —
+ * enumerate then open, like node-midi. openVirtualPort is POSIX-only and
+ * fences at runtime on Windows (WinMM has no user-space virtual ports).
+ * on/once accept ONLY the "message" event with a (deltaTime, message)
+ * handler; message bytes arrive as a number[] with deltaTime (seconds
+ * since the previous message, 0 for the first) as the leading argument —
+ * the node-midi callback shape. sendMessage takes an array literal or a
+ * Uint8Array; the runtime is byte-transparent (it neither parses nor
+ * validates MIDI semantics). */
+declare module "midi" {
+  export class Input {
+    getPortCount(): number;
+    getPortName(port: number): string;
+    openPort(port: number): void;
+    openVirtualPort(name: string): void;
+    closePort(): void;
+    isPortOpen(): boolean;
+    ignoreTypes(sysex: boolean, timing: boolean, activeSensing: boolean): void;
+    on(event: "message", listener: (deltaTime: number, message: number[]) => void): void;
+    once(event: "message", listener: (deltaTime: number, message: number[]) => void): void;
+  }
+  export class Output {
+    getPortCount(): number;
+    getPortName(port: number): string;
+    openPort(port: number): void;
+    openVirtualPort(name: string): void;
+    closePort(): void;
+    isPortOpen(): boolean;
+    sendMessage(message: number[] | Uint8Array): void;
+  }
+}
+declare module "node:midi" {
+  export * from "midi";
+}
+
 /* node:worker_threads — the MAIN-THREAD slice only. A compiled binary is
  * always the main thread (no JS-engine thread machinery exists), so
  * isMainThread lowers to `true` and threadId to 0 — Node's main-thread
@@ -3133,7 +3174,9 @@ declare module "node:async_hooks" {
  * checks annotated listener parameters against it (unannotated non-empty
  * parameter lists have no static types and fence at the registration). */
 declare module "events" {
-  class EventEmitter {
+  // Node 24 makes EventEmitter generic; the native surface remains
+  // intentionally event-name agnostic, but accepts that type argument.
+  class EventEmitter<T = any> {
     constructor();
     static defaultMaxListeners: number;
     on(eventName: string, listener: (...args: any[]) => void): this;