Release: develop -> main - #1220
Merged
Merged
Conversation
* fix(lint): cover .tsx files in the lint globs
eslint "{src,apps,libs,test}/**/*.ts" never matched a .tsx file, so all 261
.tsx files under src/ stayed outside the standalone lint run. Widen both globs
to *.{ts,tsx} and clear the 15 findings that surfaced -- all of them in
src/__tests__/, none in app code:
- drop three dead `const React = require('react')` from jest.mock factories
(the automatic JSX runtime makes them unnecessary)
- replace the never-settling `new Promise(() => {})` executors
- turn no-var-requires off for src/__tests__/** only, where jest.mock hoisting
forces require() inside the factory
No rule was downgraded or disabled to make the run pass.
* fix(lint): match the repo's disable convention, guard story files
Follow-ups on the widened lint glob:
- Replace the .eslintrc.js overrides block with the inline
eslint-disable-next-line directives the repo already uses for hoisted
jest.mock factories (see support-issue-receiver-iban.test.tsx). The blanket
override contradicted that convention, left those three directives dead, and
missed src/util/__tests__ and src/hooks/wallets/__tests__ anyway.
- Ignore **/*.stories.tsx. tsconfig.json excludes them, so under the widened
glob the type-aware parser turns any story file into a fatal parse error --
which would red the lint step that gates the dev and prd deploys.
- Add --max-warnings 0. Test files are not compiled by webpack, so npm run lint
is now their only gate and warnings would otherwise never fail it. Verified a
no-op today: 0 warnings across all 409 files.
- Widen the jest collectCoverageFrom glob the same way; it carried the
identical .ts-only bug.
- Convert the last jest.mock factory with a bare return body to the concise
form used by the other two.
* fix(ci): count ESLint message lines, not substrings, in the review bot
--max-warnings 0 made npm echo the flag into the output the review bot greps,
so grep -c "warning" counted the command line itself and the bot posted
"ESLint: 0 errors, 1 warnings" on a clean tree. Anchor both counters to real
ESLint message lines and call npm with --silent.
The same anchoring repairs a pre-existing miscount: grep -c "error" was also
matching the file name transaction-document-error.test.tsx and the summary
line, reporting 3 errors where there was 1.
Verified over four cases -- clean tree 0/0, one planted warning 1/0, one
planted error 0/1, and an error in a file whose name contains "error" 0/1,
where the old counter reported 1 warning and 3 errors.
* fix(ci): stop the TypeScript check writing a stray line to GITHUB_OUTPUT
grep -c prints 0 and exits 1 when nothing matches, so `$(grep -c … || echo
"0")` captures "0\n0" on every green run. The step then appends a bare "0"
line to $GITHUB_OUTPUT, which the runner rejects as an invalid file command
and marks the step failed -- masked only by continue-on-error.
Same pattern the ESLint counter two steps above just moved away from; this was
the last instance in the file.
* fix(ci): guard the audit counters and match .tsx in the build excludes
Two more instances of the classes this branch is already fixing:
- The Security Audit step's HIGH/CRITICAL substitutions were unguarded, so
under bash -e a missing or unparseable audit-output.json aborts the step
before either echo. Both outputs stay unset, the bot reads parseInt('') || 0
and reports no critical vulnerabilities -- and npm audit runs nowhere else,
so that comment is the only audit signal there is. Simulated valid, empty,
invalid and missing input: the old form exits 5 and 2 on the last two and
writes nothing.
- tsconfig.build.json excluded **/*spec.ts and **/*.test.ts, which do not
match .tsx -- the same bug as the lint glob. Inert only because every
.test.tsx currently sits under src/__tests__, caught by another entry; a
.test.tsx next to its component would be emitted into dist/ by build:lib.
Written as explicit patterns because TypeScript's include/exclude do not
support brace expansion, so the {ts,tsx} form matches nothing.
Verified with tsc --listFiles both ways, and build:lib still passes.
* fix(ci): report an unusable npm audit instead of silently reading zero
Guarding the audit counters in ff3ce70 fixed the aborted step but hardened
the wrong side: a broken audit became green AND silent, where the abort had
at least been visible. Report it instead.
jq -e without a `// 0` fallback separates a genuine 0 from an unavailable
metric, so the step now emits status=ok|failed and the bot says
"vulnerability status unknown" rather than nothing. Verified across seven
inputs -- clean, real vulns, npm error object, empty, invalid JSON, array,
missing file: only the first two report ok, and the error-object case is one
a `// 0` fallback would have reported as a clean audit.
Also add **/*.stories.tsx to tsconfig.build.json: extends REPLACES exclude
rather than merging it, so rewriting that array dropped the parent's story
exclusion. A story file would otherwise land in the published dist/ and,
since there is no @storybook dependency, red the bot's tsc step. Confirmed
with tsc --listFiles that it is excluded again.
* fix(ci): retry a failed npm audit once and make the failure diagnosable
Follow-ups on the audit signal:
- Retry once, gated on whether the output is usable rather than on the exit
code. npm audit exits non-zero whenever it finds vulnerabilities -- 180 in
this repo -- so retrying on exit code would run it twice on every normal PR.
Verified with a stub npm: the healthy shapes make one call, the broken ones
two. This matters because the audit is the only network-dependent check in
the job, and a transient blip posts a security warning that a later clean
run cannot clear.
- Keep stderr and print it, plus the head of the output, on the failure path,
and emit ::warning::. "Vulnerability status unknown" with an empty log gives
a maintainer nothing to act on.
- jq -s with .[0] so two concatenated JSON documents cannot produce a two-line
value and corrupt GITHUB_OUTPUT -- the same class the tsc counter hit. Not
reachable from npm audit today, but free to rule out.
The real npm audit output still resolves to status=ok high=67 critical=0.
github-actions
Bot
requested review from
TaprootFreak and
davidleomay
as code owners
July 30, 2026 18:47
The chart mode of GET /dashboard/financial/log (byType=false) returns only timestamp, totalBalanceChf and btcPriceChf. Everything else is omitted there, because deriving it would mean parsing a ~43 kB JSON document per data point. FinancialLogEntry declared those omitted fields as guaranteed numbers, so the type promised what the chart mode does not deliver. Nothing breaks at runtime today - the overview screen reads none of them - but the next person to reach for entry.plusBalanceChf on that screen would be told by the compiler that it is a number, and get undefined. Split the type instead of widening it: FinancialLogChartEntry carries the three fields the chart mode returns, FinancialLogEntry extends it with the full-mode fields. The mode is now picked by which hook function you call, not by a boolean argument, so a caller cannot ask for one shape and be typed as the other. The history screen and its components keep using FinancialLogEntry unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automatic Release PR
This PR was automatically created after changes were pushed to develop.
Commits: 1 new commit(s)
Checklist