-
Notifications
You must be signed in to change notification settings - Fork 183
experiment: @typescript/native-preview compiler for 5-6x faster local builds, 33% faster CI #4923
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- Install @typescript/native-preview@7.0.0-dev.20260106.1 - Remove baseUrl from all tsconfig.json files (not supported by native compiler) - Update all build scripts to use npx @typescript/native-preview - Fix import in layers/bin/layers.ts to use relative path with .js extension - Native compiler provides 5-6x faster compilation (256ms vs 1,574ms clean builds) - Stricter type checking catches additional type errors - Maintains compatibility with existing build system and project references
The native TypeScript compiler has stricter type checking that catches additional type errors in the codebase. Reverting to regular tsc while keeping the baseUrl removal to test CI performance impact of configuration changes alone.
- Restore npx @typescript/native-preview usage in all build scripts - Fix decorator type errors with (originalMethod as any).apply() - Add proper return type annotation for BedrockFunctionResponse.build() - Import BedrockAgentFunctionResponse type - Native compiler now builds successfully with 5-6x performance improvement
| let result: unknown; | ||
| try { | ||
| result = await originalMethod.apply(this, args); | ||
| result = await (originalMethod as any).apply(this, args); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm presuming these are unavoidable with the extra strictness of the new compiler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to figure this out - I'm not keen on keeping the any, once we can drop support for legacy decorators (addressed in v3 discussion) the implementation here would change though.
|
|
Closing for now, see PR body for details |
|
Great deep dive @dreamorosi. I fully agree with your conclusions. |



Summary
TL;DR: Native TypeScript compiler delivers 5-6x faster local builds and 33% faster CI builds, but we won't adopt it due to its experimental status and requirement for less strongly-typed decorator implementations. We'll revisit in v3 or when it becomes stable.
Performance Results
Local Development:
CI Environment:
Technical Changes
@typescript/native-preview@7.0.0-dev.20260106.1baseUrlfrom alltsconfig.jsonfiles (not supported by native compiler)npx @typescript/native-previewlayers/bin/layers.tsto use relative path with.jsextension(originalMethod as any).apply()- reduces type safetyMethodology
Local Testing:
@aws-lambda-powertools/commonspackageCI Analysis:
Decision Rationale
While performance improvements are substantial, we're not adopting the native compiler because:
@typescript/native-previewis development/preview softwareas anycasts in decorator implementationsWe'll reconsider adoption when:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.