fix: add .js extensions for NodeNext module resolution

[schickling]

Summary

This PR fixes TypeScript module resolution for consumers using moduleResolution: "NodeNext".

• Add .js extensions to all relative imports/exports in TypeScript source files
• Convert directory imports like ./lib to ./lib/index.js
• Convert from "." imports to from "./index.js"

Problem

When TypeScript processes the package with moduleResolution: "NodeNext", it cannot resolve re-exports like export * from "./renderer" because NodeNext requires explicit file extensions. This causes TypeScript to report errors like:

Module '"@opentui/core"' has no exported member 'BoxRenderable'.
Module '"@opentui/react"' has no exported member 'createRoot'.

Solution

Add explicit .js extensions to all relative imports/exports. TypeScript understands that ./renderer.js refers to ./renderer.ts during compilation, and the generated .d.ts files will have the correct extensions for NodeNext resolution.

Test plan

• Verified the fix with the reproduction at https://github.com/schickling-repros/opentui-nodenext-issue
• TypeScript trace resolution shows all relative imports are successfully resolved
• No new TypeScript errors introduced (existing errors in examples/tests remain)

Fixes #504

---

Generated with Claude Code

[pkg-pr-new]

@opentui/core

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core@614

@opentui/react

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/react@614

@opentui/solid

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/solid@614

@opentui/core-darwin-arm64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-darwin-arm64@614

@opentui/core-darwin-x64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-darwin-x64@614

@opentui/core-linux-arm64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-linux-arm64@614

@opentui/core-linux-x64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-linux-x64@614

@opentui/core-win32-arm64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-win32-arm64@614

@opentui/core-win32-x64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-win32-x64@614

commit: e5bb983

[msmps]

@schickling mind running a quick prettier:write from the root?

[schickling]

@msmps Thanks for the review! I've resolved the merge conflict and run prettier:write as requested.

Resolved:

• Merged latest main branch changes
• Fixed conflict in Markdown.test.ts by combining both the .js extensions (for NodeNext compatibility) and the new TextRenderable import from upstream
• Applied prettier formatting

Ready for another look!

[simonklee]

@msmps Is this generally a good approach - i don't write ts enough to know. I guess you could also rewrite the extensions during compile for the .d.ts files since js is only required here.

[msmps]

@msmps Is this generally a good approach - i don't write ts enough to know. I guess you could also rewrite the extensions during compile for the .d.ts files since js is only required here.

it's a good and uniform approach! i think we need to introduce a linter though like eslint, biome or oxlint to enforce the js extension going forward so this doesn't become a regression! i have a branch locally for that but would like your thoughts on this @simonklee @kommander

[simonklee]

oxlint (and oxfmt) seem to work well in the projects i've tried them in.