-
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(deps): update typescript
to 4.9.5
#3952
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3952 +/- ##
==========================================
+ Coverage 93.13% 93.14% +0.01%
==========================================
Files 298 298
Lines 8869 8869
Branches 1826 1826
==========================================
+ Hits 8260 8261 +1
+ Misses 609 608 -1 |
typescript
to 5.1.3
typescript
to 4.9.5
72fac96
to
50cd98a
Compare
Is there a difference in the generated d.ts files which requires consumers to use also a newer TS version? |
I think it is safe upgrading minor versions. |
I think we should leave this PR open a bit to allow people to review it. I'll also review the generated files to ensure we're not missing anything. There can be breaking changes in typescript minor versions as typescript does not follow semver. We'll have to look though: https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#breaking-changes and ensure we're not affected. |
I compared the output. All types in new Before export declare type HrTime = [number, number]; After export type HrTime = [number, number]; I think it is safe to upgrade. |
Yes, the only other difference I've seen is -export declare const parseResponseStatus: (kind: SpanKind, statusCode?: number | undefined) => SpanStatusCode;
+export declare const parseResponseStatus: (kind: SpanKind, statusCode?: number) => SpanStatusCode; and that should also be fine from what I can tell. Anyway: I'd rather be cautious so let's leave this PR open and see if others have a different opinion. If not then I'll merge this on Wednesday. 🙂 EDIT: A diff of the d.ts files for other reviewers to look at -> pichlermarc/inspect-3952@b4a2f4b |
Marc is definitely correct there are breaking changes in minor TS versions and breaking changes in the output. There are projects like https://github.com/sandersn/downlevel-dts which allow you to publish types compatible with old ts versions in parallel with modern types. The 2 changes to the output relevant to us are: Looking at marc's diff I don't see anywhere these are used in the output, but they could be at any point in the future. Right now if we try to use these features Typescript will simply fail to compile. If we upgrade our TS version and some PR uses either of these features in the future then we will be breaking users. Ideally I would like to see at least one of the following if not both in order to accept this PR:
|
Do we have such statement in the docs saying we support [email protected]? If not, I think doing such compatibility support is kind of redundant as it works for now and we don't promise to support [email protected] in the future. BTW, I think we should upgrade to ts@5 in the next major release. |
We do this implicitly by adhering to semver.
Yes, we discussed this a few times in the SIG meeting already, but we did not have an issue as of now. I created one and added it to the 2.0 milstone: #3955 🙂 |
API compatibility with different ts versions is hard in general. New ts versions may have better type checking which may result in broken builds. Also built in types in typescript may have impact. Also minor changes in types only may cause breakage independent of the ts version. So keeping 100% compatibility with typescript in mind is quite hard, if only the pure JS API surface is taken it's by far easier. We had several issues in the past that adding a private member in an exported class caused issues. So maybe we have to even specify a fix ts version to ensure no breakage happens. But that would be quite bad. |
In my opinion, users usually use the latest I suggest using |
This PR 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. |
@llc1123, there has been some movement on this issue: We plan to update typescript to the most recent version with a 2.0 release of the SDK (#4083), as we've concluded this will be a breaking change. We may also introduce a policy that will allow us to bump typescript more regularly without having to bump the major version, similar to what other projects do, though this is still up for debate (i'll link the issue here once it's available). Though with the currently proposed approach of one major release each year, we'll probably also be able to keep typescript reasonably up-to-date without this policy. Edit: note that SDK 2.0 is still in a planning phase, actual implementation work will start in October (current estimation). |
LGTM. I've been really busy recently and didn't have time to look at the updates. I'll be back in October and take care of the remaining issues. |
This PR 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. |
There's currently a PR incoming from #3955 which will bump typescript to 5.2 (this is for the 2.0 release)
|
I'll close this PR in the meantime. |
Which problem is this PR solving?
typedoc-plugin-resolve-crossmodule-references
is now deprecated andtypedoc >= 0.24.0
has the function built-in.typedoc >= 0.24.0
requirestypescript >= 4.6.0
Short description of the changes
typescript
to4.9.5
.** I tried upgrading to
typescript@5
but it doesn't support node < 12 anymore so I used the last version ^4Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: