-
Notifications
You must be signed in to change notification settings - Fork 825
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.0.4
#5145
base: main
Are you sure you want to change the base?
chore!: update typescript to version 5.0.4
#5145
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5145 +/- ##
==========================================
- Coverage 94.63% 94.61% -0.02%
==========================================
Files 323 323
Lines 8083 8083
Branches 1643 1643
==========================================
- Hits 7649 7648 -1
- Misses 434 435 +1
|
I starting to think that maybe we need a |
@pichlermarc @dyladan |
@@ -129,39 +129,3 @@ jobs: | |||
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }} | |||
with: | |||
verbose: true | |||
api-eol-node-test: |
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.
note for reviewer: TypeScript 5.0+ removes support for Node.js <=12.0
.mocharc.yml
Outdated
@@ -1 +1 @@ | |||
require: 'ts-node/register' | |||
require: 'ts-node/register/transpile-only' |
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.
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.
CONTRIBUTING.md
Outdated
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 --> |
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.
note for reviewer: any other items we can add to this list?
5.6.3
api/package.json
Outdated
@@ -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", |
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.
@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:
- We can't stay on 4.4.4 forever
- 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?)
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.
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 with5.6.3
, and that checks if current features compile with TypeScript4.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.
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? |
CHANGELOG_NEXT.md
Outdated
@@ -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 |
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.
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.
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.
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 :)
CONTRIBUTING.md
Outdated
|
||
<!-- 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: |
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.
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: ..."?
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.
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
tsconfig.base.esm.json
Outdated
@@ -2,6 +2,6 @@ | |||
"extends": "./tsconfig.base.es5.json", | |||
"compilerOptions": { | |||
"module": "ES6", | |||
"moduleResolution": "node" | |||
"moduleResolution": "node10" |
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.
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.)
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 thought once we have TS updated we could do this change within the scope of #4898 but I'm okay to change it
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.
at the end it was necessary even for tsconfig.base.json
file. So now they all have node16
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.2': '2022-05-24T18:38:10.371Z',
'5.1.3': '2023-06-01T17:29:55.756Z', Probably updating to |
Maintainers discussed this this morning, and it was briefly discussed in the JS SIG today: https://docs.google.com/document/d/1tCyoQK49WVcE-x8oryZOTTToFm7sIeUhxFPm9g-qL1k/edit?tab=t.0#heading=h.fkh7ke2ibqcf Consensus seemed to be to follow DefinitelyType's support policy for TypeScript (https://github.com/DefinitelyTyped/DefinitelyTyped#support-window), which is supporting 2-year old typescript. Targetting Feb/Mar 2025 for the 2.0 release, we figure that means we can bump to TypeScript 5.0.x.
|
Note npm view typescript time
...
'5.0.2': '2023-03-16T16:41:18.461Z',
'5.1.0-dev.20230325': '2023-03-25T07:12:38.653Z',
'5.0.3': '2023-03-30T20:51:58.227Z',
'5.1.0-dev.20230405': '2023-04-05T07:15:19.127Z',
'5.0.4': '2023-04-07T17:52:25.635Z', <-- this is the latest
... |
…lemetry-js into next-update-typescript
5.6.3
5.0.4
@@ -109,10 +109,10 @@ | |||
"prettier": "3.3.3", | |||
"process": "0.11.10", | |||
"semver": "7.6.3", | |||
"typedoc": "0.22.18", | |||
"typedoc-plugin-missing-exports": "1.0.0", | |||
"typedoc-plugin-resolve-crossmodule-references": "0.2.2", |
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.
note for reviewer: package author recommends to update typedoc
and remove this dependency https://www.npmjs.com/package/typedoc-plugin-resolve-crossmodule-references
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.
thanks for working on this 🙂
We also used to add typesVersions
fields in package.json
s for packages that have different entrypoins. They were only needed for typescript 4.4.4 compatibility, we may be able to remove those as well (can also be done in a a follow-up, but we should track that).
We may not be able to remove that for semantic-conventions
since we'd be dropping support in a minor version, but we'll but we might be able to do it with the otlp-exporter-base
package.
TypeScript has to be temporarily bumped because msw listed it as a optional peerDependency with an incompatibile version range, which is a strange thing to do IMO, but nevertheless this shouldn't be an issue in the long run, since open-telemetry#5145 will bump us to 5.0 anyway.
I guess I should target this one to ref: #5284 |
Yes, It'll make larger changes easier since we don't have to merge back and forth anymore. |
#### TypeScript version & update policy | ||
|
||
TypeScript version used to compile the pacakges is `v5.0.4`. If you plan to use any of the packages from this | ||
repository to make your own application or package instrumentation make sure to use same version or higher. | ||
|
||
<!-- Ref: https://github.com/open-telemetry/opentelemetry-js/pull/5145#issuecomment-2518263890 --> | ||
As update policy OpenTelemetry JS will follow DefinitelyType's [support policy for TypeScript](https://github.com/DefinitelyTyped/DefinitelyTyped#support-window) | ||
which sets a support window of 2 years. | ||
|
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.
It may be good to have this be more visible by also stating something similar in README.md - while it's important for contributors to know how we're using typescript, there's an effect on end-users that we should communicate. 🙂
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.
would be e01cd50 enough?
Closes: #4870
Checklist: