chore(ui): Upgrade TypeScript 5.6.2 plus types devDependencies in ui

[pedrottimark]

Description

https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/

https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#disallowed-nullish-and-truthy-checks

the compiler now errors when it can syntactically determine a truthy or nullish check will always evaluate in a specific way.

Note that certain expressions are still allowed, even if they are always truthy or nullish. Specifically, true, false, 0, and 1 are all still allowed despite always being truthy or falsy.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#region-prioritized-diagnostics-in-editors

When TypeScript’s language service is asked for the diagnostics for a file (things like errors, suggestions, and deprecations), it would typically require checking the entire file. Most of the time this is fine, but in extremely large files it can incur a delay.

Instead of just requesting diagnostics for a set of files, editors can now also provide a relevant region of a given file – and the intent is that this will typically be the region of the file that is currently visible to a user.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#granular-commit-characters

TypeScript’s language service now provides its own commit characters for each completion item. Commit characters are specific characters that, when typed, will automatically commit the currently-suggested completion item.

What this means is that over time your editor will now more frequently commit to the currently-suggested completion item when you type certain characters.

What’s next?

microsoft/TypeScript#59905

TypeScript 5.7 Final Release target is 2024-11-21 around sprint 4.7C

Errors

src/Containers/Vulnerabilities/WorkloadCves/Tables/table.utils.ts:255:5 - error TS2322: Type '{ vulnerabilityId: string; cve: string; operatingSystem: string; severity: "UNKNOWN_VULNERABILITY_SEVERITY" | "LOW_VULNERABILITY_SEVERITY" | "MODERATE_VULNERABILITY_SEVERITY" | "IMPORTANT_VULNERABILITY_SEVERITY" | "CRITICAL_VULNERABILITY_SEVERITY"; ... 5 more ...; pendingExceptionCount: number; }[]' is not assignable to type 'FormattedDeploymentVulnerability[]'.
  Type '{ vulnerabilityId: string; cve: string; operatingSystem: string; severity: "UNKNOWN_VULNERABILITY_SEVERITY" | "LOW_VULNERABILITY_SEVERITY" | "MODERATE_VULNERABILITY_SEVERITY" | "IMPORTANT_VULNERABILITY_SEVERITY" | "CRITICAL_VULNERABILITY_SEVERITY"; ... 5 more ...; pendingExceptionCount: number; }' is not assignable to type 'FormattedDeploymentVulnerability'.
    Types of property 'affectedComponentsText' are incompatible.
      Type 'string | undefined' is not assignable to type 'string'.
        Type 'undefined' is not assignable to type 'string'.

255     return deployment.imageVulnerabilities.map((vulnerability) => {
        ~~~~~~

Found 1 error in src/Containers/Vulnerabilities/WorkloadCves/Tables/table.utils.ts:255

Apparently a side-effect for work on iterators (that I omitted from the high points).

Because uniqueComponents.size === 1 add as string type assertion.

Although [...uniqueComponents] would be even clearer, TypeScript compiler sees "target": "es5" even though webpack and babel use "browserslist": ["Chrome >= 80"] from package.json file.

Residue

1. Investige whether compile and Visual Studio Code editor can play by the same rules as build.
2. Even if not, what are pro and con of downlevelIteration option?
   https://www.typescriptlang.org/tsconfig/#downlevelIteration

Bonus

1. Update 4 types packages which affect compile and lint.
2. Add npm run tsc to scripts, because npm run build takes several minutes and seems to stop at first compile error.
   Note: although yarn tsc was possible without need to add to scripts, even better to make the command visible (beyond necessity to do so).

Addendum

Thank you, David for insightful review comments.

Would bumping up the target to es2015 or higher also be viable given our expected browser support matrix?

Indeed, "target": "es2020" in tsconfig.json file is compatible with "browserslist": ["Chrome >= 80"] in package.json file.

Maybe reduced complications has achieved reduced confusion. I thought I had tried that multiple times without success in the past.

my initial thought was this would be more readable as …

After I verified that [...set] worked with update to target I replaced the code with more readable suggestion.

User-facing documentation

• CHANGELOG update is not needed
• documentation PR is not needed

Testing and quality

• the change is production ready: the change is GA or otherwise the functionality is gated by a feature flag
• CI results are inspected

Automated testing

• added unit tests
• added e2e tests
• added regression tests
• added compatibility tests
• modified existing tests

How I validated my change

1. npm run lint in ui/apps/platform
2. npm run build in ui/apps/platform and then compute branch - master for the following
   • wc build/static/js/*.js
     main.js -2043 = 4616822 - 4618865
     total -1838 = 11699313 - 11701151
   • ls -al build/static/js/*.js | wc
     files 0 = 177 - 177
3. npm run start in ui/apps/platform

Manual testing

1. Visit /main/vulnerabilities/workload-cves, click Deployments, and then in table body, click deployment link:

   • Before change: see presence of TypeScript error and name if one component in Affected components
     

   • After change: see absence of TypeScript error and ditto in Affected components

Integration testing

• vulnerabilities/workload-cves/deploymentSingle.test.js

[pedrottimark]

ui-component-tests failure

INFO: Mon Sep 16 16:18:51 UTC 2024: Will use junit2jira to create CSV for BigQuery input
time="2024-09-16T16:18:51Z" level=info msg="Found 0 failed tests"
INFO: Mon Sep 16 16:18:51 UTC 2024: Saving Big Query test records from /tmp/tmp.cokc0P0ljG.csv to gs://stackrox-ci-artifacts/test-metrics/upload
Copying file:///tmp/tmp.cokc0P0ljG.csv [Content-Type=text/csv]...
/ [0 files][ 0.0 B/ 66.0 B]
ServiceException: 401 Anonymous caller does not have storage.objects.create access to the Google Cloud Storage object. Permission 'storage.objects.create' denied on resource (or it may not exist).

[pedrottimark]

/test ui-component-tests

[rhacs-bot]

Images are ready for the commit at 11d1347.

To use with deploy scripts, first export MAIN_IMAGE_TAG=4.6.x-513-g11d134784a.

[pedrottimark]

/test ocp-4-16-ui-e2e-tests
/test ocp-4-16-nongroovy-e2e-tests

[dvail]

Although [...uniqueComponents] would be even clearer, TypeScript compiler sees "target": "es5" even though webpack and babel use "browserslist": ["Chrome >= 80"] from package.json file.

Agreed, and when I saw the diff before reading the PR description my initial thought was this would be more readable as:

const uniqueComponents = uniq(allVulnerableComponents.map((c) => c.name));
   const affectedComponentsText =
       uniqueComponents.length === 1
           ? uniqueComponents[0]
           : `${uniqueComponents.length} components`;

so even as the original author I'm not crazy about the Set/Iterator approach here in hindsight.

---

Also, here is an item from the release notes I've been looking forward to as a DX enhancement:

https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#exclude-patterns-for-auto-imports

[pedrottimark]

@dvail Did the lack of downlevelIteration push you toward a less readable solution originally?

Especially if yes, the compiler option seems like a worthwhile follow up.

[dvail]

Did the lack of downlevelIteration push you toward a less readable solution originally?

I honestly don't recall.

I think in concept the downlevelIteration flag could be useful for this type of thing, but I encounter that type of error very rarely, and I do worry a bit about changing the compiled JavaScript behavior on an app this large. We also don't run on anything that wouldn't have Symbol.iterator right? Would bumping up the target to es2015 or higher also be viable given our expected browser support matrix?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 48.17%. Comparing base (1a1b841) to head (11d1347).
Report is 9 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #12709      +/-   ##
==========================================
+ Coverage   48.15%   48.17%   +0.02%     
==========================================
  Files        2434     2434              
  Lines      174159   174160       +1     
==========================================
+ Hits        83864    83906      +42     
+ Misses      83510    83475      -35     
+ Partials     6785     6779       -6     

Flag	Coverage Δ
go-unit-tests	48.17% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.