fix(codegen): omit .js in imports of generated files

[milankyncl]

Description

Removal of .js extension in imports of generated files.

Why I raised this PR

I'm using this library within a Next.js project with TypeScript, which uses a strict compiler configuration. Files generated by codegen are TypeScript-based (so do they have extension .ts) but imports have .js extension so after running the project complier raises following error:

./src/__generated__/xyz/xyz_nft.ts:12:0
Module not found: Can't resolve '../utils/index.js'

Test plan

By manually editing generated files and then running the project again.

---

AI Assistance Notice

Please disclose the usage of AI. This is primarily to help inform reviewers of how careful they need to review PRs, and to keep track of AI usage across our team. Please fill this out accurately, and do not modify the content or heading for this section!

• This PR was primarily written by AI.
• I used AI for docs / tests, but manually wrote the source code.
• I used AI to understand the problem space / repository.
• I did not use AI for this PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
sui-typescript-docs	Ready	Preview	Comment	Sep 5, 2025 11:33am

[hayes-mysten]

Thanks for opening this PR. Unfortunately I think this issue is more complicated that it appears.

Would you be able to provide a reproduction of the next.js setup you are using that surfaces this issue?

The codegen package is used in several other SDKs in this repo, and the.js extensions are required for these SDKs to be build correctly. Using full file paths (rather than expecting directories to automatically resolve to index.js/index.ts) and including the .js extension is a requirement for esm support to work consistently across various environments. This requirement is somewhat specific to libraries, which are compiled and shipped/executed with .js files.

This explains why we need .js extensions in the compiled library code, but not why it needs to be in the typescript files. The issue there is that typescript (and several other compilers/bundlers) do not support transforming the import paths as part of compiling typescript to javascript. This is well documented in the typescript docs, and is not something that is likely to change in the typescript compiler any time soon. The official recomendation from the typescript team is that typescript should be authored with .js extensions in the imports, and MOST tools (typecsript, vite, bun, deno, node) all understand this pattern and will correctly resolve these imports.

There is a new setting in typescript allowImportingTsExtensions which allows for .ts imports, but only when using --noEmit, and is only intended for cases where code is not compiled to js.

I think we could potentially add an option to the config for omitting extensions from the compiled code but I would recommend exploring if there is a simple fix to the config for you project that will handle the code as is, because the .js extension pattern is fairly standard across the ts ecosystem