Skip to content

Support TypeScript 7.1 API - #1704

Draft
johnnyreilly with Copilot wants to merge 75 commits into
mainfrom
copilot/implement-new-tsgo-api-support
Draft

Support TypeScript 7.1 API#1704
johnnyreilly with Copilot wants to merge 75 commits into
mainfrom
copilot/implement-new-tsgo-api-support

Conversation

Copilot AI commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

This PR migrates ts-loader to fully support and integrate with the TypeScript 7.1+ Native API (powered by the tsgo engine). Ignore the ESLint failures - TypeScript ESLint also doesn't yet support TS 7. It'll come!

The implementation has moved past the initial hybrid/experimental design to route core operations through the native typescript/unstable/sync architecture by default. Historical TypeScript version dependencies have been removed in favour of direct 7.1 alignment.

🚀 What Changed

  • Default Native Architecture: The native API path (experimentalNativeApi: true) is now the default behavior for the loader.
  • Legacy API Removal: Cleaned up historical TypeScript compiler API dependencies, porting internal compilation machinery to target TypeScript 7 native synchronous entry points directly.
  • Async Instance Setup: Maintained async loader instance creation to dynamically resolve and load the native ESM sync compiler APIs at runtime.
  • CI Test Suite Updates: Shifted the workflow matrix to target the 7.1 compiler layer, addressing and adapting tests for rootDir, declaration output, watch behaviors, and error formatting (resolveJsonModule, onlyCompileBundledFiles).

📦 Integration Details

  • Native Emit Path (/src/native.ts): Opens and manages native snapshots, uses getJavaScriptEmit for file emissions, and registers project dependencies natively with Webpack.
  • Diagnostic Mapping: Translates native compiler diagnostics directly into native Webpack module errors.
  • Compatibility Layer: Preserves existing source mapping and module completion handling to ensure seamless integration with modern Webpack builds, alongside localized fixes for legacy Webpack 4 setups.

🧪 Verification Status

  • yarn build compiles successfully against the native TS7 target architecture.
  • Full execution test suites run and pass cleanly against the 7.1.0-dev core matrix.
  • (Note: Historic loaderOptions testing has been bypassed or updated to reflect the new default baseline)..

@johnnyreilly

Copy link
Copy Markdown
Member

@copilot update

ts: [5.6.2, 5.7.2, 5.8.2, 5.9.2, 6.0.2] # next excluded for now
and
ts: [5.6.2, 5.7.2, 5.8.2, 5.9.2, 6.0.2] # next excluded for now
to only cater for: 7.1.0-dev.20260725.1 - the existing versions specified do not contain the new API.

We expect execution-tests to pass after this change

Copilot AI commented Jul 26, 2026

Copy link
Copy Markdown
Contributor Author

@copilot update

ts: [5.6.2, 5.7.2, 5.8.2, 5.9.2, 6.0.2] # next excluded for now
and https://github.com/TypeStrong/ts-loader/blob/53082fbe1cdeb560b6...

Updated in fcc8a21 to run the execution-test matrix only against 7.1.0-dev.20260725.1. I also verified the native path locally with yarn build && yarn execution-tests -- --single-test nativeApiTranspile.

@johnnyreilly

Copy link
Copy Markdown
Member

@copilot great work! We would like the following to succeed:

yarn build && yarn execution-tests

Remember backwards compatibility is not required - feel free to make changes

Copilot AI commented Jul 26, 2026

Copy link
Copy Markdown
Contributor Author

@copilot great work! We would like the following to succeed:

yarn build && yarn execution-tests
...

Verified on fcc8a21: yarn build && yarn execution-tests now succeeds locally (30 execution suites passed).

@johnnyreilly

Copy link
Copy Markdown
Member

@copilot we have explictly removed the historic typescript version from dependencies and moved to use 7.1 directly. This has broken compilation. Please fix it. You will likely need to use new APIs in TypeScript 7 to achieve this. No cheating.

Copilot AI commented Jul 27, 2026

Copy link
Copy Markdown
Contributor Author

@copilot we have explictly removed the historic typescript version from dependencies and moved to use 7.1 directly. This has broken compilation. Please fix it. You will likely need to use new APIs i...

Updated in 4706cfe. yarn build now passes against direct TypeScript 7 by routing the loader through typescript/unstable/sync instead of the removed legacy compiler API.

@johnnyreilly

Copy link
Copy Markdown
Member

@copilot make experimentalNativeApi: true the default behaviour and ensure execution-tests pass. We are happy to ignore loaderOptions test for now

Copilot AI commented Jul 27, 2026

Copy link
Copy Markdown
Contributor Author

@copilot make experimentalNativeApi: true the default behaviour and ensure execution-tests pass. We are happy to ignore loaderOptions test for now

Addressed in 048c5ce. The native execution test now relies on the default native API path, loaderOptions is skipped for now, and yarn build && yarn execution-tests passes locally.

…by testing

Isolated and reverted each individually against real Windows CI (full suite
where the change had broad reach, targeted tests otherwise) - all three
passed without the change, confirming they were never load-bearing:

- bumpMtimes in the comparison-test harness: added chasing a watchpack
  mtime-equality theory for dependencyErrors that turned out wrong; the
  actual fix was in getDirectResolvedImports (already in place).
- ensureSyntheticConfigForFile's files-array path normalization: added
  before the real fix (syntheticConfigContents' store-side key
  normalization, which remains); the API evidently normalizes each
  files-array entry internally regardless of separator style.
- registerTypeScriptDependencies' getConfigFileNames loop normalization:
  added speculatively alongside the confirmed addDependency fix in the
  same edit; never independently exercised by any actual failure.

Full local suite (50/50) and full Windows CI suite (50/50) still pass
with all three removed.
@johnnyreilly

Copy link
Copy Markdown
Member

Custom transformers and transpile support in the API can be tracked here: microsoft/TypeScript#63875

@johnnyreilly

Copy link
Copy Markdown
Member

Add support for transpile directly now this PR has landed: microsoft/typescript-go#4849 (comment) courtesy of @andrewbranch - expected in nightlies soon

@johnnyreilly

johnnyreilly commented Aug 20, 2026

Copy link
Copy Markdown
Member

3b5af16 added support for microsoft/typescript-go#4849. Very smooth initial migration. Claude picked up a potential issue which I have reported here: microsoft/typescript-go#4849 (comment)

Windows comparison tests are failing right now - fixing.

johnnyreilly and others added 2 commits August 20, 2026 17:22
api.transpileModule/transpileDeclaration build their own virtual
filesystem from `fileName` verbatim rather than resolving it through a
Project, so an OS-native (backslash) path panics on Windows ("mixed
posix and windows paths") and also breaks diagnostic location lookup
(the echoed diagnostic.fileName no longer matches the OS-native
apiFileName used as the lookup key).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
api.transpileDeclaration builds its own throwaway virtual filesystem
from `fileName` verbatim rather than resolving it through a Project,
and panics on Windows ("mixed posix and windows paths") given any
absolute path there - OS-native or forward-slash-normalized alike.
Stripping the OS-native configFilePath from compilerOptions and
falling back a rootDir were both tried first and, per the Windows
test probe workflow, neither stopped the panic.

The actual fix: pass transpileDeclaration a bare basename instead of
any absolute path at all. Unlike transpileModule (which needs
fileName's real directory for e.g. rootDir-containment diagnostics
like TS6059, and keeps its own absolute, forward-slash path),
transpileDeclaration doesn't need real directory context - its own
diagnostics (isolatedDeclarations violations) are purely syntactic,
and any real rootDir violation for the same file is already caught by
transpileModule's own call on it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@johnnyreilly
johnnyreilly force-pushed the copilot/implement-new-tsgo-api-support branch from a2ad345 to 7f1cbd5 Compare August 20, 2026 19:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants