Typescript compatiblitly

Flarna commented 3 years ago

[x] This only affects the JavaScript OpenTelemetry library
[ ] This may affect other libraries, but I would like to get opinions here first

Followup on https://github.com/open-telemetry/opentelemetry-js-contrib/pull/549#discussion_r664733898

Currently we use the latest version of typescript in our CI setup and we also use the latest features like override keyword. Besides such "visible" features like override there are also more hidden features like better type deduction,... which would result in problems if people try to use an older version.

If someone would like to consume the raw TS files the same, new typescript version is needed which if often challenging.

As of now it should be no problem for consumers of transpiled packages but I'm not sure if there is a gurantee from TS side regarding this compatiblity.

@MSNev indicates that they would prefer a more conservative approach regarding this.

I think this is a valid point to consider. But if we decide to go this way I think following points should be done:

sync API, core and contrib repo regarding the version used
use this older typescript version in CI to ensure no new feature is used
clearly document this decission
specify a timeframe for updating typescript to avoid we stick on an ancient version forever
specify if moving to a newer typescript version is semver major or minor

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

github-actions[bot] commented 2 years ago

This issue was closed because it has been stale for 14 days with no activity.

legendecas commented 2 years ago

I'd believe we can set up alternative CI for the latest and older typescript versions for 1. testing generated d.ts compatibility, 2. source code compatibility. (1) should be the most common one since most consumers depend on the published d.ts files. (2) might not be that popular option since we didn't publish the ts source files anyway.

As TypeScript generally releases every 3 months, I'd believe supporting the latest 2-4 versions should cover 6 months of upgrading period. For above (1) and (2), I suppose we can apply different rules for them:

(This is just a possible solution)

for generated d.ts consumers, we guarantee 3 versions / 6 months (latest+2 versions) of typescript support,
for source code consumers, we guarantee 2 versions / 3 months (latest+1 versions) of typescript support.

For version bumping, https://github.com/open-telemetry/opentelemetry-js/issues/3314 our cadence of release should be considered. I don't see another major version bump will happen in the near future, but we have to let go of the older typescript versions.

Ugzuzg commented 2 years ago

TypeScript supports specifying different .d.ts files for different versions: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#version-selection-with-typesversions

downlevel-dts rewrites .d.ts files created by any version of TypeScript so that they work with TypeScript 3.4 or later. This package is used by typescript-eslint, for example.

dyladan commented 3 months ago

Closed in favor of #4870

open-telemetry / opentelemetry-js

Typescript compatiblitly #2329