Support ESM

[emoriwan]

Closes #59

[pirog]

@emoriwan not a bad first attempt. Given that we keep bumping into longer issues we might want to spin up an AGENTS.md for this repo based on some of our other tanaab js projects that use LEIA. Also what's up with all th le fixturws? Shouldn't we be using LEIA itself in the examples folders to test all this stuff? That's where the love fixtures should go like in each separate examples folder. We also should matrix run -esm vs common vs auto if possible for all those tests if that is something that can work. Can you think about all of this and come back with a plan to improve the pr?

[emoriwan]

@pirog

I received your comment, but I couldn't safely publish the detailed response. I've kept it in the linked private session for review.

[emoriwan]

Revised plan applied

Follow-up commits through 9eddabf implement the agreed test split:

• Added root and examples/ agent guidance defining unit-versus-scenario ownership.
• Moved CommonJS, ESM, untyped, and nested package scopes into live examples/module-formats/ scenarios, including the legacy .js failure demonstration.
• Kept the existing macOS, Ubuntu, and Windows matrices; they now exercise auto from each scenario directory with repository-local temporary output.
• Added a separate Ubuntu matrix for explicit commonjs and esm runs across the Leia suite and package-scope overrides.
• Removed the subprocess integration spec and format duplication from the OS shell jobs.
• Corrected the lint failures reported on the first push.

Validation is complete: all 15 lint, unit, Leia, shell, and module-format checks pass across the supported matrix.

[pirog]

@emoriwan ok this is looking much better but

1. do we need the readme.md edit about the PR stuff?
2. shouldnt we name our new format test in examples format-examples to fit the style of the other folder names?
3. its nice that all the examples run but shouldnt we actually test somehow in our examples that the correctly generated file exists and is actuall esm or cjs or do our unit tests cover that
4. we probably should update to the latest pinned versions of the hosted runners and we can probably consolidate to a single macos-26 runner

what do you think?

[emoriwan]

@pirog

Agreed on all four:

1. Remove the PR/CI paragraph from README; keep the user-facing module-format documentation.
2. Rename examples/module-formats to examples/format-examples.
3. The script currently checks the expected extension exists, while unit tests inspect syntax. I’d strengthen the example test to require exactly one harness, reject the opposite extension, and verify a format-specific source marker.
4. Update runner pins repo-wide to current GA versions: ubuntu-24.04, windows-2025, and one macos-26. Ubuntu 26.04 is still preview, so we should not pin it yet. Official runner catalog

That trims prose, sharpens the integration contract, and cuts redundant macOS jobs.