Skip to content
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

chore!: update typescript to version 5.6.3 #5145

Open
wants to merge 16 commits into
base: next
Choose a base branch
from

Conversation

david-luna
Copy link
Contributor

@david-luna david-luna commented Nov 12, 2024

Closes: #4870

Checklist:

  • Update typescript to 5.6.3
  • Document our new minimum typescript version
    • Document a policy for updating typescript in minor versions in the future
  • Add a test project to ensure that minimum typescript version can compile using the updated otel dependencies

Copy link

codecov bot commented Nov 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.14%. Comparing base (4a394cc) to head (7d71e92).
Report is 4 commits behind head on next.

Additional details and impacted files
@@            Coverage Diff             @@
##             next    #5145      +/-   ##
==========================================
- Coverage   93.15%   93.14%   -0.02%     
==========================================
  Files         315      315              
  Lines        8113     8106       -7     
  Branches     1633     1633              
==========================================
- Hits         7558     7550       -8     
- Misses        555      556       +1     
Files with missing lines Coverage Δ
...es/opentelemetry-instrumentation-grpc/src/utils.ts 84.61% <ø> (ø)

... and 5 files with indirect coverage changes

@david-luna
Copy link
Contributor Author

I starting to think that maybe we need a next branch in the contrib repository so we can sync this type of changes 🤔

@david-luna
Copy link
Contributor Author

  • Add a test project to ensure that minimum typescript version can compile using the updated otel dependencies

@pichlermarc @dyladan
I see a project name esm-http-ts within examples folder. Could that be our testing project? or it's preferable to have something more complex within integration-tests maybe?

@david-luna david-luna marked this pull request as ready for review November 18, 2024 15:50
@david-luna david-luna requested a review from a team as a code owner November 18, 2024 15:50
@@ -129,39 +129,3 @@ jobs:
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
with:
verbose: true
api-eol-node-test:
Copy link
Contributor Author

@david-luna david-luna Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note for reviewer: TypeScript 5.0+ removes support for Node.js <=12.0

@@ -1 +1 @@
require: 'ts-node/register'
require: 'ts-node/register/transpile-only'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note for reviewer: extracted from https://github.com/open-telemetry/opentelemetry-js-contrib/pull/2481/files#r1807185358. Type checking is done in compilation process so it's okay to skip here.

TypeScript version used to compile the pacakges is `v5.6.3`. If you plan to make your own instrumentation script
in a `.ts` file it is recommended to use same version or higher.

<!-- TODO: review the update policy -->
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note for reviewer: any other items we can add to this list?

@david-luna david-luna changed the title chore: update typescript chore!: update typescript to version 5.6.3 Nov 18, 2024
@@ -98,7 +97,7 @@
"nyc": "15.1.0",
"sinon": "15.1.2",
"ts-loader": "9.5.1",
"typescript": "4.4.4",
"typescript": "5.6.3",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@open-telemetry/javascript-maintainers what do you think about making this change in the API package? I think we should probably just go for it:

  1. We can't stay on 4.4.4 forever
  2. We don't want to go to API 2.0 any time in the foreseeable future

I think for both of these to be true, we have to eventually make this change in a minor API version, painful though it may be to some small number of users.

In order to not make this change, we'd have to keep a different version of typescript here than everywhere else. IDK how painful this would be in practice in our monorepo (maybe not that bad?)

Copy link
Member

@pichlermarc pichlermarc Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I think at least typedoc is coupled with the typescript version - so it may hold us back with quite a few dependencies as well. I'm for updating. Maybe we could do the following:

  • we compile using [email protected]
  • we add a integration test package (not linked to the monorepo) that installs the local @opentelemetry/api compiled with 5.6.3, and that checks if current features compile with TypeScript 4.4.4 and only runs in the test workflow. Maybe it even works fine since we're not using any new TypeScript features. 🤔
    • If it does work fine the question might become: do we want to allow new API features that use new TypeScript features that would not work with 4.4.4 in minor versions?

Here's me hoping that bumping the API major will be allowed at some point in the future.

Edit: the reason we don't do is because of this spec, and 2.0 milestone scope creep, right? Dropping language version support has its own spec actually and says that we should follow the conventions given by the ecosystem (which would be bumping major). This spec does not explicitly prohibit it.

@trentm
Copy link
Contributor

trentm commented Nov 26, 2024

  '5.6.3': '2024-10-08T22:01:09.783Z',

TypeScript 5.6.3 is a fairly recent release. Is there a reason for or against 5.6.3 specifically? Was 5.6.3 the latest release at the time you started working on this PR?

@@ -25,5 +25,6 @@

* chore: remove checks for unsupported node versions [#4341](https://github.com/open-telemetry/opentelemetry-js/pull/4341) @dyladan
* refactor(sdk-trace-base): remove `BasicTracerProvider._registeredSpanProcessors` private property. [#5134](https://github.com/open-telemetry/opentelemetry-js/pull/5177) @david-luna
* chore: update typescript to version `^5.6.3` [#5145](https://github.com/open-telemetry/opentelemetry-js/pull/5145) @david-luna
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This almost certainly should move up to the "breaking change" section, no?

Also should that say 5.6.3 rather than ^5.6.3? The package.json files below (at least some of them) pin the version.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At 1st I checked https://github.com/microsoft/TypeScript/wiki/Breaking-Changes and was hesitating since I'm not completely sure how the produced types may break user apps. Also I've tried using ^ in dependencies, its a leftover.

Thanks for spotting it. I'll move it up :)


<!-- TODO: review the update policy -->
Also TypeScript is meant to be updated in compatible verisons of `5.x`. However there could be scenarios
where we might don't want to update the minor version:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is likely my TypeScript-ignorance: What is TypeScript's definition of "compatible versions", if not all of "5.x"?

Or could I be misunderstanding what you are saying? Are you saying "all updates of TS 5.x to a later 5.x version is meant to be compatible, but here is a list of reasons that might not be true for us: ..."?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes a TS release has this paragraph that makes me be cautious about updating versions.
See: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#lib.d.ts-changes

@@ -2,6 +2,6 @@
"extends": "./tsconfig.base.es5.json",
"compilerOptions": {
"module": "ES6",
"moduleResolution": "node"
"moduleResolution": "node10"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We specifically need node10 and not node16?
https://www.typescriptlang.org/tsconfig/#moduleResolution
(I am pretty ignorant here, but it seems odd given that our base supported Node.js version for the "next" branch will be node 18.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought once we have TS updated we could do this change within the scope of #4898 but I'm okay to change it

@david-luna
Copy link
Contributor Author

  '5.6.3': '2024-10-08T22:01:09.783Z',

TypeScript 5.6.3 is a fairly recent release. Is there a reason for or against 5.6.3 specifically? Was 5.6.3 the latest release at the time you started working on this PR?

It was the latest release. I tried how far I could update the version and it turns out we can aim the latest. I guess you're asking because we may reduce the number of users affected (app or instrumentation script compilation errors) by having lower version.

About type changes most of the are related on inference when coding and it should not affect our exports. I think the most interesting feats are:

These are the publish dates of the lowest 4.7.x and 5.1.x

'4.7.2': '2022-05-24T18:38:10.371Z',
'5.1.3': '2023-06-01T17:29:55.756Z',

Probably updating to v4.7.2 will be enough for the features we want 🤔

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.

4 participants