chore(deps): bump typescript-eslint to 8.56.1#109312
Conversation
| exports: moduleExports, | ||
| }, | ||
| }; | ||
| return callback(null, `export default ${JSON.stringify(typeLoaderResult)}`); |
There was a problem hiding this comment.
@typescript-eslint/await-thenable: neither extractComponentProps nor extractModuleExports return a Promise. There's no need to Promise.all them. This is a case newly caught by typescript-eslint/typescript-eslint#11611.
Technically, this is a behavior change. If the code throws an error I think there might be a difference in error handling. It looks safe but I don't have enough context yet in the code to feel safe making that statement. Because this is "just" stories I'll go forward with requesting review.
| options={(activePlan.planCategories[category] || []).map( | ||
| (level: {events: {toLocaleString: () => any}}) => ({ | ||
| // eslint-disable-next-line @typescript-eslint/no-base-to-string | ||
| label: level.events.toLocaleString(), |
There was a problem hiding this comment.
@typescript-eslint/no-base-to-string: this false positive was accidentally fixed in typescript-eslint/typescript-eslint#11901. TIL! 😄
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| metricAlertQuota && | ||
| metricAlertQuota.detectorLimit === metricAlertQuota.detectorCount + 1 | ||
| ) { | ||
| if (metricAlertQuota?.detectorLimit === metricAlertQuota.detectorCount + 1) { |
There was a problem hiding this comment.
Asymmetric optional chaining could crash on right operand
Low Severity
The prefer-optional-chain lint fix transformed metricAlertQuota && metricAlertQuota.detectorLimit === metricAlertQuota.detectorCount + 1 into metricAlertQuota?.detectorLimit === metricAlertQuota.detectorCount + 1. Unlike &&, the === operator always evaluates both sides — so optional chaining on the left doesn't protect the bare metricAlertQuota.detectorCount access on the right from throwing if the value were ever nullish. The original && short-circuited the entire expression safely. While useMetricDetectorLimit currently always returns a non-null object, this pattern is inconsistent and fragile.
There was a problem hiding this comment.
I think Cursor is wrong here. From what I can tell, file and the codebase around it doesn't do any weird unusual logic that would cause property accesses on metricAlertQuota to have side effects (e.g. computed getters, null!/undefined! values). But someone please tell me if I'm wrong?!
There was a problem hiding this comment.
It doesn't look like it's necessary to have the optional check here anymore either. It seems like metricAlertQuota should always be defined. Drilling into the hook shows that these fields are always supplied. imo yes, I think Cursor's wrong and it's confused thinking that metricAlertQuota can be null/undefined when it can't be
I see there's some code above that does the same check, I think it's fine if we ignore it but I think either we should link our optional chaining when it's not necessary or just fix this one case, but a linting rule would be good 🙏
There was a problem hiding this comment.
Confirmed! @narsaynorath showed me how to get to this component. For posterity:
- It's under
/monitors/new, which you need to be in the alpha rollout for - In
detectorTypeForm.tsx, changecanCreateMetricDetectortofalse - In this file, set
metricAlertQuota.hasReachedLimit = true;



I noticed while working on #109310 that the latest version of
@typescript-eslint/prefer-optional-chainwasn't being used. Some code snippets like this weren't being reported:That was fixed by typescript-eslint/typescript-eslint#11533. This PR bumps typescript-eslint to the latest version and fixes new lint rule reports. It was mostly prefer-optional-chain reports; others are noted inline.
Fixes https://linear.app/getsentry/issue/ENG-6929/bump-typescript-eslint-to-855