Skip to content

Maintenance: Remove baseUrl from TypeScript configurations for future compiler compatibility #4924

@dreamorosi

Description

@dreamorosi

Summary

Remove the baseUrl: "." configuration from all TypeScript configuration files across the monorepo and update any affected import paths. This change prepares the codebase for potential future adoption of Microsoft's native TypeScript compiler while maintaining full compatibility with the current TypeScript compiler. The change involves updating 22+ tsconfig files and fixing one import path in the layers directory.

Why is this needed?

During experimentation with Microsoft's @typescript/native-preview compiler, we discovered significant performance improvements (5-6x faster local builds, 33% faster CI builds). However, the native compiler doesn't support the baseUrl configuration option, which is currently present throughout our TypeScript configs. Removing baseUrl now provides several benefits: (1) prepares the codebase for potential future native compiler adoption when it becomes stable, (2) eliminates an unnecessary configuration option that's not actively used for module resolution in our project, (3) aligns with modern TypeScript best practices that favor explicit relative imports, and (4) reduces technical debt by cleaning up legacy configuration. This is a low-risk change that maintains full backward compatibility while positioning us for future performance improvements.

Which area does this relate to?

Other

Solution

  1. Remove baseUrl: "." from all tsconfig.json and tsconfig.cjs.json files across packages
  2. Update the import in layers/bin/layers.ts to use relative paths with .js extensions
  3. Verify all builds continue to work correctly
  4. Update any documentation that references the baseUrl configuration

The implementation is straightforward and can be done with automated find/replace operations followed by testing to ensure no regressions.

Acknowledgment

  • This request meets Powertools for AWS Lambda (TypeScript) Tenets
  • Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Metadata

Metadata

Assignees

Labels

completedThis item is complete and has been merged/shippedinternalPRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)

Type

No type

Projects

Status

Shipped

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions