Skip to content

Upgrading three dependencies - #1303

Merged
ckeshava merged 4 commits into
ripple:mainfrom
ckeshava:typescriptDepUpgrade
Mar 25, 2026
Merged

ckeshava merged 4 commits into
ripple:mainfrom
ckeshava:typescriptDepUpgrade

Conversation

@ckeshava

Copy link
Copy Markdown
Contributor

High Level Overview of Change

As indicated by the commit messages, this PR upgrades three dependencies. The following extant PRs are obviated by this work:
#1242
https://github.com/ripple/explorer/pull/1221/changes
#1201

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactor (non-breaking change that only restructures code)
  • Tests (You added tests for code that already exists, or your new feature included in this PR)
  • Documentation Updates
  • Translation Updates
  • Release
  • dependency upgrade

Test Plan

Existing tests pass with the upgraded dependencies. No functional change in the working of Explorer.

The upgraded typescript compiler has a different method overload resolution order. Hence, the useTranslation().t method had to be modified to ensure specificty in overload resolution.
- remove @types/testing-library__jest-dom because the above package ships it own types
- there is no need to instruct tsc to explicitly import the types of @testing-library/jest-dom since the imports are self-contained during the compilation process

afterEach(() => {
client.close()
// @ts-expect-error - restoring original location after test override

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I was wondering why is this change relevant to the dependency upgrade?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This diff is needed because of the major version upgrade of typescript dependency. The setter method for the location property has changed in the two versions.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

let me think of a more elegant way for this problem

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

ok, this commit introduces a better usage of this API. It no longer resorts to evading the type-error with ts-expect-error directive.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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


const getNetworkName = (network: string) =>
t(`network_name`, { context: network })
t(`network_name`, { context: network, defaultValue: network })

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I was wondering why is this change relevant to the dependency upgrade?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Without this change, I get the following error from tsc

src/containers/Header/NetworkPicker/NetworkPicker.tsx:43:7 - error TS2345: Argument of type '["network_name", { context: string; }]' is not assignable to parameter of type '[key: "number" | "object" | "other" | "action" | "escrow" | "seconds" | "version" | "quorum" | "load" | "domain" | "fee" | "total" | "source" | "destination" | "yeas" | "nays" | "not" | ... 177 more ... | ("number" | ... 192 more ... | "prepayment")[], options?: { ...; } | undefined] | [key: ...] | [key: ...]'.
  Type '["network_name", { context: string; }]' is not assignable to type '[key: string | string[], defaultValue: string, options?: ({ readonly context: string; } & $Dictionary) | undefined]'.
    Type at position 1 in source is not compatible with type at position 1 in target.
      Type '{ context: string; }' is not assignable to type 'string'.

43     t(`network_name`, { context: network })
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This PR upgrades the typescript compiler. The overload resolution logic has been updated because there is a major version upgrade typescript v4 -> v5.

The clue is in this message Type '["network_name", { context: string; }]' is not assignable to type '[key: string | string[], defaultValue: string, options?: ({ readonly context: string; } & $Dictionary) | undefined]'. --> If we want to specify a context value, then we must also specify a defaultValue (in case the internationalised translation is unavailable).

Apart from the complaints from tsc, I think this is a good change. It provides a necessary default, if explorer is used in a hitherto unknown language.

…t API for window.location assignment in typescript v5.9
Comment thread src/setupTests.ts
@@ -1,5 +1,5 @@
import 'dotenv/config'
import '@testing-library/jest-dom/extend-expect'
import '@testing-library/jest-dom'

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

this subpath was removed from the @testing-library/jest-dom pacakge. These exports were provided at the root-level of the package

Comment thread tsconfig.json
"esModuleInterop": true,
"jsx": "react-jsx",
"lib": ["dom", "dom.iterable", "esnext"],
"types": ["jest", "@testing-library/jest-dom"],

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

these types had to explicitly added in prior versions of @testing-library/jest-dom during the compilation process. However, the newer release of this library self contains the types. Hence, there is no need to explicitly mention it as a config option for tsc

@ckeshava
ckeshava requested a review from kuan121 March 25, 2026 19:15
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.

3 participants