Activity

1. johnnyreilly commented on May 23, 2025

   

   johnnyreilly

   on May 23, 2025

   Member

   More actions

   I saw it was released but I haven't experimented with it. Please do have a try and report back!

   However, please note that the expectation is that transpileOnly: true is likely to work but that transpileOnly: false (type checking mode) is unlikely to work, and not expected to in future either.

   Read this for more detail: https://johnnyreilly.com/typescript-go-pragmatic-choice#ecosystem-tools
2. tmm1 commented on Jul 22, 2025

   

   tmm1

   on Jul 22, 2025

   More actions

   tsgo is currently very good at typechecking, but the emit paths are wip so it cannot produce valid JS for a lot of cases
3. errorx666 commented on Apr 27, 2026

   

   errorx666

   on Apr 27, 2026

   Contributor

   More actions

   This is now in beta, so I expect renewed interest in this.

   👍React with 👍1Reacted by elitastic
4. johnnyreilly commented on Apr 27, 2026

   

   johnnyreilly

   on Apr 27, 2026

   Member

   More actions

   As I understand it, there's no API available yet. I think the API is scheduled to ship with 7.1 - @acutmore that's right I think?
5. acutmore commented on Apr 27, 2026

   

   acutmore

   on Apr 27, 2026

   Contributor

   More actions

   That's correct. 7.0 only has the CLI.

   An importable API is scheduled for 7.1.

   As there are no new syntax features in 7.0 the existing ts-loader will still be compatible with 7.0 code.

   ❤️React with ❤️2Reacted by John Reilly and South Drifter
6. danielweck commented on Apr 30, 2026

   

   danielweck

   on Apr 30, 2026

   More actions

   Also see: TypeStrong/fork-ts-checker-webpack-plugin#892
7. errorx666 commented on Jul 10, 2026

   

   errorx666

   on Jul 10, 2026

   Contributor

   More actions

   https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

   ERROR in ./src/service/index.ts
   Module build failed (from ./node_modules/ts-loader/index.js):
   TypeError: Cannot read properties of undefined (reading 'fileExists')
       at findConfigFile (C:\build\src\error-chrome-host\node_modules\ts-loader\dist\config.js:92:29)
       at getConfigFile (C:\build\src\error-chrome-host\node_modules\ts-loader\dist\config.js:43:28)
       at successfulTypeScriptInstance (C:\build\src\error-chrome-host\node_modules\ts-loader\dist\instances.js:117:58)
       at getTypeScriptInstance (C:\build\src\error-chrome-host\node_modules\ts-loader\dist\instances.js:86:12)
       at Object.loader (C:\build\src\error-chrome-host\node_modules\ts-loader\dist\index.js:59:67)
   

   The line from the stack trace:

   return compiler.sys.fileExists(configFile) ? configFile : undefined;
8. johnnyreilly commented on Jul 10, 2026

   

   johnnyreilly

   on Jul 10, 2026

   Last edited by johnnyreilly

   Member

   More actions

   I'm pretty sure that all of what we need isn't there yet to migrate ts-loader to ts7 yet. I threw Claude at the problem and it came up with this view:

   TypeScript 7 / tsgo (native preview) — where ts-loader stands

   TypeScript 7.0 is the Go-native rewrite of the compiler (package @typescript/native-preview, binary tsgo). It's dramatically faster than the classic JS compiler, so it's natural to ask when/how ts-loader can move onto it. This doc captures the current state of that investigation so it doesn't need re-deriving each time it comes up.

   The short version

   There's currently no API for ts-loader to migrate onto. @typescript/native-preview is CLI-only — it does not export createProgram, createLanguageService, transpileModule, or anything else ts-loader calls. The TypeScript team has said a programmatic API is planned for TypeScript 7.1+, with no committed date, and that they're still in early design on it (there's an
   internal libsyncrpc sync-IPC layer, not a public API).

   Practically, this means: if a project's typescript dependency resolves to @typescript/native-preview, ts-loader breaks today with a cryptic TypeError: ts.createProgram is not a function (or the equivalent for transpileModule in transpileOnly mode) — this exact failure has already been reported against ts-loader in third-party TS7 compatibility testing.

   Why full type-checking mode (transpileOnly: false) can't migrate yet

   ts-loader's default mode is built on API surface that has no native-preview equivalent at all:

   • createLanguageService / createDocumentRegistry — src/instances.ts:424-426
   • createWatchProgram and builder programs — src/instances.ts:394-415, src/servicesHost.ts:554-613
   • createSolutionBuilderWithWatch for project references — src/instances.ts:543-596,
     src/servicesHost.ts:765-914
   • Custom transformers threaded through emit — src/instances.ts:442-478, 784-838
   • Assorted private/internal APIs already guarded with as any — src/instances.ts:609-704

   None of this is on native-preview's near-term roadmap. There's no narrow slice of it that can be ported piecemeal the way, say, ts-blank-space did in bloomberg/ts-blank-space#69 — that migration only needed to parse source into an AST and blank out type annotations, with no type-checking, no Program, and no watch/incremental state. Even that narrow surface hit real bugs along the way (AST start/end position drift, and UTF-8(Go)/UTF-16(JS) string offset mismatches) before landing a net perf win. ts-loader's full-checking mode has no comparably narrow surface to aim at.

   Why transpileOnly: true is the only currently-relevant path

   transpileOnly: true only calls compiler.transpileModule() (src/index.ts:657) — no Program or LanguageService involved. That's structurally the closest thing ts-loader has to what ts-blank-space needed. But transpileModule isn't exported by native-preview either, so this isn't an in-process API swap today — it's the existing decoupled pattern ts-loader already supports: transpile fast in-process (via the classic typescript package), and check for real types in a separate process.

   ts-loader already documents exactly this split for speed reasons (see the transpileOnly section and the fork-ts-checker-webpack-plugin example). For TypeScript 7 adopters, the same shape applies: transpileOnly: true in ts-loader, and tsgo --noEmit (directly, or once fork-ts-checker-webpack-plugin grows tsgo support) as the type-checking step. See examples/typescript-7-tsgo for a working demonstration of this pairing.

   Revisiting this

   Re-evaluate once TypeScript 7.1 ships a real programmatic API. At that point the open questions are: does it expose anything Program/LanguageService-shaped, or only a parser/transpile surface; and does it support custom transformers and incremental/watch builds, which ts-loader also depends on for its default mode.

   See also: https://thinkingthroughcode.medium.com/i-tested-15-popular-libaries-with-typescript-7-toolchain-heres-how-to-fix-broken-migration-7ea719018e6d

   Emit API has landed: microsoft/typescript-go#4699

   Available in: TypeScript version 7.1.0-dev.20260725.1 and greater

   👍React with 👍3Reacted by error, Anton Bessonov and Alexander Akait

   👎React with 👎1Reacted by Cynthia

   ❤️React with ❤️1Reacted by Daniel Weck

   👀React with 👀1Reacted by error
9. johnnyreilly commented on Jul 25, 2026

   

   johnnyreilly

   on Jul 25, 2026

   Last edited by johnnyreilly

   Member

   More actions

   Not tested in any way as yet, but copilot has come up with this: #1703

   And because that was very verbose I asked it to implement a version without backwards compatibility:

   #1704

   Also not tested yet

   This shows promise. Execution tests are passing and some comparison tests are passing.

   👀React with 👀2Reacted by South Drifter and Joel Sison
10. nils44344 commented on Sep 23, 2026

    

    nils44344

    on Sep 23, 2026

    More actions

    For anyone who needs webpack + ts-loader working on TypeScript 7 today, while a native-API migration is pending: Microsoft's side-by-side setup from the TypeScript 7.0 announcement works with the current ts-loader, no changes to webpack.config needed.

    npm install -D "@typescript/native@npm:typescript@7.0.2" "typescript@npm:@typescript/typescript6@^6.0.2"

    tsc resolves to the Go compiler, while require('typescript') — which is what ts-loader calls — gets the 6.x API from the compat package.

    Tested on Windows 11, Node 24.14.0, webpack 5.111.1, ts-loader 9.6.2, same project, only the typescript entries changed:

    Setup	npx tsc --version	npx webpack
    typescript@6.0.3	6.0.3	compiled successfully
    typescript@7.0.2	7.0.2	TypeError: Cannot read properties of undefined (reading 'fileExists') at successfulTypeScriptInstance (dist/instances.js:117:58)
    side-by-side (above)	7.0.2	compiled successfully

    The crash on plain 7 is because the package only exports ['version', 'versionMajorMinor'], so ts.sys is undefined when ts-loader reads the tsconfig.

    One trap worth knowing: --legacy-peer-deps (the usual answer to the ERESOLVE you get elsewhere in a TS 7 project) skips installing all peer deps, not just the conflicting one — in the same test it silently dropped Vite from under Vitest. The side-by-side setup installs cleanly without it.

    Runnable reproduction: https://github.com/nils44344/node-ts-error-repros/tree/master/05-typescript-7-side-by-side

    👍React with 👍3Reacted by John Reilly, Cynthia and Alex
11. skurekjakub

    added a commit that references this issue on Oct 6, 2026

    Bump ralphchives and discord-hitl dependencies to latest

    ...

    2cdfa16