Will typescript-go support importing .ts extensions?

[alexgleason]

Will TypeScript 7 support modern path-resolution like Vite, esbuild, etc?

There's a tc39 proposal for browsers to support type stripping, so that TypeScript files could be imported and run directly in the browser.

It raises the question of what a TypeScript source file "should" look like. TypeScript is an idealized form of JavaScript, with the role of tsc being to transform the idealized form into the compatible form.

The world has overwhelmingly chosen .ts imports. It would be a huge win if typescript 7 could eclipse bundlers.

EDIT: I forgot to mention, I know that TypeScript 5.7 introduced the rewriteRelativeImportExtensions option, but it is an incomplete imlementation that doesn't support path aliases like @/utils/example.ts

[RyanCavanaugh]

TS7 will have the same module primitives (minus deprecated ones) as TS 5.9/6.0

What you're describing is already broadly possible with allowImportingTsExtensions. Path rewriting of path mapping is not a planned new feature, and is unlikely to be implemented -- TypeScript's goal is to check types, not bundle files, so supplanting bundlers is out of scope for the project.

[alexgleason]

Thank you for the response.

The way I see it, there are 2 different variants of TypeScript. When people use bundlers, they think they're using TypeScript but they're actually not...

I don't get not wanting to address this. If bundlers are required to use TypeScript the way the world wants to use it, I would consider removing the "emit" functionality of TypeScript.

[RyanCavanaugh]

You can use a bundler or not use a bundler with TypeScript. Plenty of people do both.

There are many moving parts in the dev ecosystem -- typechecking, bundling, dev servers, hot module reloads, culling unused styles, accessibility checking, A/B testing, metrics, GDPR compliance, routing, and so on.

TypeScript doesn't need to be an omni-tool that does all of these. Bundlers do an extremely good job of what they need to do, the same can be said of many other things too. Defining the project scope in terms of focusing on one important thing seems to make a lot of sense to me.

[GuitaristForEver]

TypeScript’s stance is that it focuses on type-checking, not replacing bundlers or loaders. In fact, modern TypeScript already provides an option to allow direct .ts imports: the --allowImportingTsExtensions compiler flag lets you import files with their .ts extension in code . Additionally, TypeScript 5.7 introduced --rewriteRelativeImportExtensions to automatically turn relative .ts imports into .js in the emitted output . This means if you run TypeScript without a bundler (e.g. in Node’s native ES modules or Deno), you can use .ts in import statements and have the compiler output correct .js paths  .

However, full “bundler-like” path resolution is not planned. For example, TypeScript will not rewrite imports for your custom path aliases or bare module imports – those still require a bundler or loader. The core team has stated that supplanting bundlers is out of scope for TypeScript . TypeScript 7 (as used in the Go compiler) will have the same module resolution features as recent versions : use allowImportingTsExtensions for direct .ts imports, but don’t expect TypeScript to handle things like alias path mapping or tree-shaking.

In short, yes – you can import .ts files directly using the existing compiler options, but no – TypeScript/TS-Go won’t intrinsically handle all bundler tasks like alias rewriting or combining modules. The TypeScript team’s philosophy is that bundlers and build tools already do an excellent job at those tasks, and TypeScript should “focus on one important thing” – providing type safety . So you’ll likely continue to use bundlers (or Node’s loader hooks) for advanced resolution, while TypeScript ensures your types are checked and outputs JavaScript as needed.

For reference, the TypeScript lead has noted that features like path alias rewriting are unlikely to be added – the recommended approach is to use bundler plugins or the above compiler flags for .ts import support  . This approach keeps TypeScript simple and lets bundlers (Webpack, Vite, etc.) handle optimization and module resolution beyond .ts extension handling.