Skip to content

Feature request: consider adopting tslib for runtime helpers #1674

Closed as not planned
@dreamorosi

Description

@dreamorosi

Use case

When transpiling TypeScript code to JavaScript, tsc generates and injects helpers that allow developers to author code using a certain runtime (i.e. Node.js 18) and target other versions (i.e. Node.js 16).

The default behavior that TypeScript adopts is to include these helpers in each transpiled file that needs them. TypeScript however offers these same utilities also as a published npm package called tslib which can be installed and used as runtime dependency.

Following this pattern could potentially bring bundle size savings since the helpers are imported and present in the bundle only once rather than be present in each file that uses them. This however could also have some performance overhead for those customers who choose to not bundle their dependencies since there is now an additional dependency & files to read from disk.

The extent of the impact in both those areas is still to be assessed, however as a point of reference the AWS SDK for JavaScript v3 is using the tslib option suggested in this issue.

This behavior is governed by two compiler options: importHelpers and noEmitHelpers. As part of this work we should experiment with them and asses the following:

  1. see if the utilities can be compiled and run using helpers centrally imported from tslib
  2. see what impact this change brings to the final bundle size and I/O performance

As part of this issue, we could also explore two additional settings that might be adjacent to the ones above:

  • downlevelIteration
  • isolatedModules

Solution/User Experience

From customers perspective the change should be transparent and the utilities should continue working as intended without any change needed. However, in an effort to err on the safe side I suggest we make this change as part of the next major release, this way we'll have a chance to highlight the change in the migration guide/details and make it more explicit.

Alternative solutions

As an alternative we could leave things as they are and continue letting TS include these helpers in each file.

Acknowledgment

Future readers

Please react with 👍 and your use case to help us understand customer demand.

Metadata

Metadata

Assignees

Labels

commonsThis item relates to the Commons Utilityfeature-requestThis item refers to a feature request for an existing or new utilityrejectedThis is something we will not be working on. At least, not in the measurable future

Type

No type

Projects

Status

Closed

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions