chore(deps): upgrade all dependencies (2026-08-10) - #136
devin-ai-integration[bot] wants to merge 39 commits into
Conversation
Drops the obsolete react-virtualized 9.22.5 patch; the broken WindowScroller import is fixed upstream in 9.22.6. Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
Reformats a few files to satisfy prettier 3.9. Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
@types/lodash 4.17 types the fp intersectionWith comparator's second argument as a union of both list element types, so the destructured comparator no longer type-checks. Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
…ls/load@8.1.15 @graphql-tools/graphql-file-loader@8.1.18
…ui/lab@9.0.0-beta.8
…18 @types/react-dom@19.2.4
MUI v9 drops the Grid item/xs API used in 98 places across 19 components; migrating is a large refactor out of scope for a dependency bump. Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
v5 exports NumericFormat instead of a default export and renames isNumericString to valueIsNumericString. Also switches the husky postinstall to the husky 9 entrypoint. Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| "http-proxy-middleware": "0.19.1", | ||
| "husky": "7.0.4", | ||
| "graphql-tools": "9.0.33", | ||
| "http-proxy-middleware": "3.0.7", |
There was a problem hiding this comment.
📝 Info: Proxy path filter now actually matches GraphQL requests
The old context list contained "graphql" without a leading slash; http-proxy-middleware matches string filters as a prefix of the pathname (pathname.indexOf(context) === 0), so /graphql never matched and was never proxied by scripts/testServer.ts. The new "/graphql" entry changes that in CI (start:react:proxy-server / start:ci). In practice the frontend calls GraphQL with an absolute http://localhost:${backendPort}/graphql URL (src/machines/bankAccountsMachine.ts:53), so nothing should regress — but this is a genuine behavior change of the CI proxy server, not a pure rename.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Fixed in 6a4c6a6 — src/setupProxy.js now destructures createProxyMiddleware and uses pathFilter, and logLevel is dropped. On the "graphql" → "/graphql" change: agreed it is a behavior change rather than a rename, and it is the intended pattern (the old entry silently matched nothing). The frontend calls GraphQL at an absolute backend URL, so nothing depends on the proxy for it. yarn start:ci / scripts/testServer.ts is being verified now.
| "eslint": "^9.38.0", | ||
| "eslint-plugin-cypress": "^5.2.0", | ||
| "express": "4.20.0", | ||
| "express": "5.2.1", |
There was a problem hiding this comment.
🔍 Runtime express upgraded to 5 while @types/express stays on 4.x
express moves to 5.2.1 but @types/express (4.17.21) and @types/express-serve-static-core (4.17.2) remain pinned to v4 (the description says v5 typings break the handler signatures). This means the compiler validates the backend against Express 4 semantics while the app runs Express 5 — so genuinely breaking API differences (removed req.param, res.sendfile, path-to-regexp v8 route syntax, error-handling of rejected promises) will not be caught by yarn types. I scanned backend/*.ts and found no removed APIs or */optional-param route patterns in the app's own routes, but note backend/helpers.ts:94-96 uses unless({ path: ["/testData/*"] }) in the auth-provider code paths, whose matching semantics under the newer stack are untested by CI.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Being verified against a running server now (pagination on the feeds plus the sanitizeQuery path). If either turns out to be broken I will revert express to 4.20.0 rather than pull express-validator 7 / replace express-paginate in a dependency-bump PR.
| transactions.filter(({ id }) => | ||
| seedLikes.some(({ transactionId }) => isEqual(id, transactionId)) | ||
| ); |
There was a problem hiding this comment.
📝 Info: intersectionWith → filter/some rewrite is behaviour-equivalent here
lodash/fp intersectionWith(comparator, transactions, seedLikes) returns elements of the first array that match any element of the second, with de-duplication performed via the same comparator. Because the comparator reads transactionId off the second argument, the internal "already seen" check always compares against a value with transactionId === undefined and never matches, so no de-duplication actually occurred. The new transactions.filter(({ id }) => seedLikes.some(...)) therefore produces the same array (same order, same duplicates) for both the likes and comments call sites.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Agreed, and intentional — the inputs are shortid-keyed and unique, so the de-dup is a no-op here. Kept the simpler form rather than reaching for uniqBy.
| import NumberFormat from "react-number-format"; | ||
| import { NumericFormat } from "react-number-format"; | ||
| import { Formik, Form, Field, FieldProps } from "formik"; | ||
| import { string, object, number } from "yup"; |
There was a problem hiding this comment.
🔍 yup 0.32 → 1.x affects five form schemas, only one file touched
Only src/components/TransactionCreateStepTwo.tsx is in the diff, but yup 1 changes behavior for schemas in BankAccountForm.tsx, CommentForm.tsx, UserSettingsForm.tsx, SignUpForm.tsx and SignInForm.tsx too (mixed<T>().oneOf, ref() cross-field comparison, empty-string→NaN typeError precedence for number().required()). Nothing in those schemas is obviously broken under v1, and Formik 2.4 supports yup 1, but validation-message assertions in the Cypress e2e suite are the only real coverage for these paths.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Being checked in the browser now, including the empty-amount message on TransactionCreateStepTwo under validateOnMount. Will report back here with the result.
…iddleware 3
react-router 5 subscribes with history.listen((location, action) => ...) while history 5 passes a single { action, location } update, so the router stored a non-location and every programmatic navigation rendered a blank route. http-proxy-middleware 3 drops the default export and the (context, options) signature in favour of pathFilter.
Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
| "react": "19.2.8", | ||
| "react-calendar": "^6.0.1", | ||
| "react-dom": "19.2.8", | ||
| "react-number-format": "5.4.5", |
There was a problem hiding this comment.
📝 Info: react-virtualized under React 19 — findDOMNode removal risk
React 19 removes ReactDOM.findDOMNode, which several react-virtualized modules (notably WindowScroller) still call. src/components/TransactionInfiniteList.tsx only imports InfiniteLoader/List, which do not call it, so the transaction feed should be unaffected; the failure would only appear if WindowScroller were ever used. Flagging so the constraint is recorded, since 9.22.6 is not a React-19-aware release.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Agreed on the peer ranges. InfiniteLoader/List are the only react-virtualized imports and neither touches findDOMNode; verified in the browser that the virtualized feed renders and scrolls under React 19. MUI stays on 5.x because MUI ≥6 drops the Grid item/xs API this app uses in ~98 places.
| "@types/react-virtualized": "9.22.3", | ||
| "@types/shortid": "2.2.0", | ||
| "@types/uuid": "10.0.0", | ||
| "@types/validator": "13.15.10", | ||
| "@types/webpack-env": "1.18.8", | ||
| "@types/yup": "0.29.14", |
There was a problem hiding this comment.
📝 Info: Stale @types packages now shadowed by bundled typings
yup 1.x, uuid 14, shortid 2.2.17 and bcryptjs 3 all ship their own typings, yet @types/yup 0.29.14, @types/uuid 10, @types/shortid 2.2.0 and @types/bcryptjs 2.4.6 are retained (some merely bumped). TypeScript prefers the package's own types field, so these @types/* entries are dead weight that can drift out of sync with the runtime API; they are candidates for removal in a follow-up rather than a bump.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Agreed — leaving the removals for a follow-up so this PR stays a pure version bump. Note @types/yup is still load-bearing for one import in the current source, so it cannot be dropped blindly.
| "codesandbox:start:api": "yarn tsnode:not-instrumented --files backend/app.ts", | ||
| "codesandbox:start": "NODE_ENV=development TSC_COMPILE_ON_ERROR=true concurrently \"vite\" yarn:start:api:codesandbox", | ||
| "postinstall": "husky install && patch-package" | ||
| "postinstall": "husky && patch-package" |
There was a problem hiding this comment.
📝 Info: Leftover husky v4 config block after moving to husky 9
The postinstall script now uses husky (v9 style), but the top-level "husky": { "hooks": { "pre-push": "yarn types" } } block at package.json:199-203 is husky v4 configuration that has been ignored since v7, and .husky/ contains only a .gitignore — so no pre-push hook is actually installed. Worth either porting the hook to .husky/pre-push or deleting the dead config while touching husky.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Correct, the v4 husky block has been dead since v7. Leaving it (and the missing .husky/pre-push) alone here so this stays a dependency bump — the postinstall change was only to silence the husky install deprecation warning. Worth a follow-up to port pre-push: yarn types to .husky/pre-push.
…ort 0.7 and express 5 passport >=0.6 made req.logout async (session.save then session.regenerate), so destroying the session synchronously afterwards threw inside a processImmediate and killed the process. Express 5 exposes req.query as a lazy getter, so express-paginate's defaults and the express-validator query sanitizers were silently dropped; the query object is redefined as a writable property before those middlewares run. Co-Authored-By: Phil Bedford <phil.bedford@cognition.ai>
| // Express 5 exposes req.query as a lazy getter, so middleware that writes into it | ||
| // (express-paginate defaults, express-validator query sanitizers) has no effect. | ||
| app.use((req, _res, next) => { | ||
| Object.defineProperty(req, "query", { | ||
| value: req.query, | ||
| writable: true, | ||
| configurable: true, | ||
| enumerable: true, | ||
| }); | ||
| next(); | ||
| }); |
There was a problem hiding this comment.
🔍 Query snapshot middleware depends on Express 5's query getter staying configurable
The shim replaces the prototype-level lazy query getter with a per-request own data property. Two things worth confirming against the installed express 5.2.1: (1) the getter must not already be materialized as a non-configurable own property (otherwise Object.defineProperty throws for every request), and (2) Express 5 changed the default query parser from extended (qs) to simple (querystring.parse), which returns null-prototype objects and no longer supports nested/bracket params. The snapshot is taken with whatever parser is active, so any code that assumes qs semantics (e.g. isEmpty(req.query) / lodash helpers in backend/transaction-routes.ts:102-103 and backend/database.ts query filters) now operates on a plain, flat, null-prototype object. Worth a quick runtime smoke test of the paginated transaction endpoints.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Verified at runtime against express 5.2.1 on the running app.
Object.defineProperty does not throw: express 5 defines query as a configurable getter on the request prototype (defineGetter(req, 'query', ...) in lib/request.js), so replacing it with a per-request own data property is legal, and every request in the smoke tests below went through the shim without error.
On the query parser: app.get('query parser') reports simple under 5.2.1, but the app only ever reads flat scalar params (page, limit, q, dateRangeStart/dateRangeEnd, amountMin/amountMax), so the loss of bracket/nested support is not reachable. isEmpty/pick/omit from lodash all work on null-prototype objects.
Runtime smoke test of the paginated + filtered endpoints (logged in as a seeded user):
GET /transactions/public -> {page:1, limit:10, totalPages:5, hasNextPages:true} n=10
GET /transactions/public?page=2&limit=5 -> {page:2, limit:5, totalPages:8, hasNextPages:true} n=5
GET /transactions/public?amountMin=1&amountMax=100000 -> {page:1, limit:10, totalPages:5} n=10
GET /transactions/public?amountMin=1&amountMax=100000&page=2&limit=3 -> {page:2, limit:3, totalPages:13} n=3
GET /transactions/public?dateRangeStart=...&dateRangeEnd=... -> {page:1, limit:10, totalPages:5} n=10
Before the shim the parameterless request returned all 38 rows with totalPages: null, so the amount/date filter paths above are also confirming that the express-validator query sanitizers land.
| "@babel/preset-env": "^7.28.0", | ||
| "@cypress/code-coverage": "^3.14.5", | ||
| "@babel/preset-env": "^7.29.7", | ||
| "@cypress/code-coverage": "^4.0.3", |
There was a problem hiding this comment.
🔍 Verify @cypress/code-coverage v4 still ships the express middleware entrypoint
backend/app.ts:50 does require("@cypress/code-coverage/middleware/express")(app) when running instrumented (CYPRESS_COVERAGE=true). The plugin jumps a major version (3.x → 4.x); if that subpath entry was removed or moved behind package exports in v4, the coverage-enabled backend startup used by start:ci/tsnode would throw at require time. This path is guarded by global.__coverage__, so a normal yarn dev run would not surface it — the CI coverage run would.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Checked the installed 4.0.3: the subpath is still published, just relocated behind exports ("./middleware/express": "./dist/middleware/express.js"), so require("@cypress/code-coverage/middleware/express") resolves to dist/middleware/express.js and returns a function. The middleware/ source directory no longer exists in the package, which is exactly the case exports covers — a deep path into middleware/* would have broken, the mapped subpath does not.
node -e "console.log(typeof require('@cypress/code-coverage/middleware/express'))" -> function
Also worth noting v4 raises its cypress peer to >=15.10.0; we are on 15.20.0.
| req.logout(() => { | ||
| req.session!.destroy(() => res.redirect("/")); | ||
| }); |
There was a problem hiding this comment.
📝 Info: Logout now redirects once instead of racing two redirects
The old code called res.redirect("/") from the req.logout callback and again from the session.destroy callback, which produced an ERR_HTTP_HEADERS_SENT on whichever fired second, and also destroyed the session concurrently with logout. The new sequencing (logout → destroy → single redirect) removes both problems; note the previous destroy error argument is now discarded, so a session-store failure is silently ignored and still redirects — acceptable for the in-memory store used here.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Correct on both counts, and that double-redirect is what the fix removes. The crash I actually hit was upstream of it: passport 0.7's req.logout regenerates the session asynchronously, and the old synchronous req.session.destroy() ran first, so passport then dereferenced a destroyed session and took the backend process down with TypeError: Cannot read properties of undefined (reading 'regenerate').
The discarded destroy error is deliberate — the previous code ignored it too (it redirected regardless of err), and with the in-memory store there is no meaningful recovery beyond clearing the cookie, which already happened. Verified: POST /logout -> 302, and the API stays up afterwards (/checkAuth -> 401 rather than a dead socket).
Browser walkthrough @
|
| Logout → clean sign-in, no error banner | Re-login succeeds → API survived |
|---|---|
- Backend process stayed up 19m38s across every logout, with zero
Cannot read properties of undefined (reading 'regenerate')and zero[nodemon] app crashed— no restart masking a crash. POST /logout→ 302 (was000/severed connection),/checkAuth→ 401 afterwards, re-login → 200.
Fix 2 — Express 5 writable req.query: pagination + filters all work
GET /transactions/public with no params now returns 10 results and {page:1, limit:10, totalPages:5, hasNextPages:true} (was 38 results with page/limit absent and totalPages: null).
In the UI the feed loads exactly 10 rows and grows to ~28 on scroll with no blank rows, $NaN or $undefined. The express-validator query sanitizers that write into the same req.query also still work — no 422 on any filtered request:
Amount filter $250 – $1,000 applied |
Date filter Feb 2024 |
|---|---|
- Amount: all 10 visible rows within range (min
$283.19); smaller rows correctly dropped; Clear restores$0 - $1,000and the excluded rows return. - Date: distinct non-empty set for Feb 2024, and correctly "No Transactions" for a 2026 range (seed data spans 2023-03 → 2024-03), so the filter discriminates rather than always returning empty.
- API cross-check:
?amountMin=25000&amountMax=100000returned the identical 10 amounts rendered in the UI; the Feb range returned 6 rows all withcreatedAtin2024-02. express5.2.1 reportsquery parser: simple; the backend only reads flat scalar params (page,limit,q,dateRange*,amount*), so the loss of nested/bracket parsing is not reachable, and thequerygetter is configurable so the shim never throws.
Previously verified at 6a4c6a6 (unchanged by these backend-only commits)
history4.10.1 revert fixes the blank-feed regression: post-login redirect renders a populated feed; MINE/FRIENDS/EVERYONE update URL +aria-selected+ rows- $25 payment end-to-end: yup 1 blocks an empty note (
Please enter a note, Pay disabled),NumericFormatshows$25, submit →Transaction Submitted!, balance$1,509.53→$1,484.53, appears first in the MINE feed yarn lint,yarn types,yarn build,yarn test:unit:ci(44 passed) all green at03ad9c2yarn start:cistarts cleanly on http-proxy-middleware 3; withBACKEND_PORT=3001,/login,/checkAuth,/graphqlreturn 200application/jsonfrom the backend while/and/personalfall back to the SPA@cypress/code-coverage4 still exposesmiddleware/express(relocated behind packageexports), so the instrumented backend path inbackend/app.tsstill requires cleanly
Pre-existing, unrelated to this PR: BACKEND_PORT is never defined
src/setupProxy.js targets http://localhost:${process.env.BACKEND_PORT}, but BACKEND_PORT is set nowhere — .env only has VITE_BACKEND_PORT=3001, and it is absent from .github/ workflows, so out of the box the target is http://localhost:undefined and proxied paths return 504. develop's setupProxy.js uses the same variable, so this predates the PR, but it means yarn start:ci cannot actually proxy in CI today. Worth a separate fix (e.g. fall back to VITE_BACKEND_PORT).
This PR does fix a latent bug in the same file: develop had "graphql" without a leading slash in the context array; HEAD uses /graphql.
Console: only pre-existing stop-color/stop-opacity warnings from SvgCypressLogo.tsx, xstate deprecation warnings, and Vite/React DevTools info. No 422s, no 5xx, no React 19 or axios errors.
Summary
Upgrades every outdated npm dependency in the repo that can be upgraded without a breaking-API migration: 80 direct dependencies (18 patch, 26 minor, 36 major), plus a lockfile-only bump of
webpack5.97.1 → 5.109.2. Work is split into one commit per batch (patch/minor) and one commit per major package so any single upgrade can be reverted in isolation.Notable non-mechanical parts of the diff:
axios0.28.1 → 1.19.0 clears the largest cluster of advisories in the tree (SSRF, prototype-pollution and DoS chains, ~25 GHSAs against 0.x).react/react-dom18.2.0 → 19.2.8 (with matching@types/react*19) — verified in the browser: sign-in, XState-driven feed,react-virtualizedlist and navigation still work.http-proxy-middleware0.19.1 → 3.0.7 needs the CI proxy server's call site updated, since v3 has no default export and replaced the(context, options)signature:"graphql"entry had no leading slash, so it never matched;"/graphql"is now proxied byscripts/testServer.ts. The frontend calls GraphQL at an absolute backend URL, so nothing depended on the old behaviour.historywas attempted at 5.3.0 and reverted: react-router 5 subscribes withhistory.listen((location, action) => ...)while history 5 passes a single{ action, location }update object, so the router stored a non-location and every programmatic navigation (the post-loginhistory.push("/"), every tab click) rendered a blank route. Caught in the browser walkthrough, not by lint/build/tests.react-virtualized9.22.5 → 9.22.6 lets us deletepatches/react-virtualized+9.22.5.patch; the brokenWindowScrollerESM import that patch commented out is fixed upstream.react-number-format4 → 5 needs a call-site change, since v5 drops the default export:@types/lodash4.14 → 4.17 types thelodash/fpintersectionWithcomparator's second argument asT1 | T2, so the destructured comparators inscripts/seedDataUtils.tsno longer type-check. Both call sites were plain "keep transactions that appear in X" filters, so they are now expressed directly:passport0.5 → 0.7 breaksPOST /logout: 0.7'sreq.logoutis asynchronous and regenerates the session, but the route destroyed the session synchronously alongside it, so passport then dereferenced a destroyed session and killed the backend process withTypeError: Cannot read properties of undefined (reading 'regenerate')(it also raced twores.redirects):express4 → 5 makesreq.querya lazy getter, so middleware that writes into it silently no-ops —express-paginatecould no longer install itspage/limitdefaults (a parameterlessGET /transactions/publicreturned all 38 rows withtotalPages: nullinstead of a page of 10) and theexpress-validatorquery sanitizers inbackend/validators.tshad no effect. Snapshotting the parsed query as a writable own property restores Express 4 semantics for both:husky7 → 9:postinstallnow callshuskyinstead of the deprecatedhusky install.Version-range style is preserved per package (exact stays exact,
^stays^).Security fixes
Advisories resolved on direct dependencies (transitive fixes come along via the refreshed lockfile):
axios0.28.1 → 1.19.0passport0.5.0 → 0.7.0http-proxy-middleware0.19.1 → 3.0.7@types/jsonwebtoken8 → 9 (aligned withjsonwebtoken9 typings)morgan1.10.0 → 1.11.0uuid8 → 14webpack(lockfile) 5.97.1 → 5.109.2npm audit fix --forcewas not used; every change is an explicit version bump.Upgrade summary
Patch (18)
@mui/lab@percy/cypress@types/bcryptjs@types/bluebird@types/connect-flash@types/cors@types/dinero.js@types/json-server@types/lowdb@types/morgan@types/passport@types/react-router@types/yupcorsformikreact-calendarreact-virtualizedshortidMinor (26)
@auth0/auth0-react@babel/core@babel/plugin-syntax-flow@babel/plugin-transform-react-jsx@babel/preset-env@emotion/styled@mui/icons-material@mui/material@okta/okta-react@percy/cli@types/connect-history-api-fallback@types/express-session@types/lodash@types/react-virtualized@types/validator@types/webpack-envaws-amplifybabel-loadercypressdate-fnsexpress-sessiongraphql-httpmorganpassportprettiertypescript-eslintMajor (36)
@cypress/code-coverage@graphql-tools/graphql-file-loader@graphql-tools/load@okta/jwt-verifier@okta/okta-auth-js@types/jsonwebtoken@types/node@types/react@types/react-dom@types/shortid@types/uuidaxiosbcryptjsclsxconcurrentlyconnect-history-api-fallbackcross-envdotenvexpressfuse.jsgraphqlgraphql-toolshttp-proxy-middlewarehuskyjsdomnodemonnpmnycpatch-packagereactreact-domreact-number-formatstart-server-and-testuuidwait-onyupSkipped packages
Each was attempted on its own commit, validated, and reverted when the fix was more than a mechanical change:
@mui/material,@mui/icons-material,@mui/labGriditem/xsAPI used in 98 places across 19 components; it builds but logsReceived true for a non-boolean attribute itemat runtime and the layout silently degrades. Kept on latest 5.x (5.18.0) instead.historyhistory@^4.9.0and itsRouterlistener contract; history 5's single-argumentlistencallback breaks all client-side navigation (verified in the browser). Needs react-router 6+.react-router,react-router-domuseRouteMatch(and the v5 route-render API) are gone;TransactionNavTabs/routing need a data-router migration.xstate,@xstate/reactMachine,.withConfig, and the actor API used by all 9 machines were removed in XState 5.lowdbbackend/database.tsand the wholedb.get(...).value()chain style would have to be rewritten.dinero.jstypescripttypescript-eslintrefuses to run: "typescript-eslint does not support TS 7.0".@faker-js/fakerfaker.random.*,faker.name.*,internet.userName,phone.phoneNumberFormat,helpers.randomize), which would rewrite most ofscripts/seedDataUtils.tsand change committed seed data.express-validatorsanitizeQueryused inbackend/validators.ts.express-jwtexpressjwt), sobackend/helpers.tsno longer compiles.jwks-rsaexpress-jwttypings and requiresexpress-jwt8 (see above).@types/express,@types/express-serve-static-corebackend/user-routes.ts. Runtimeexpressitself was upgraded to 5.2.1.eslint,@eslint/js,eslint-plugin-cypresspreserve-caught-errorrule fails on existingcatchblocks — a lint-debt cleanup, not a dependency bump.@testing-library/jest-dom,@testing-library/react@testing-library/domdependency and React 19 testing setup changes; unit suite fails to resolve it.vite,@vitejs/plugin-react,vite-plugin-istanbulvite-plugin-istanbul9 is ESM-only and cannot berequired from the CJSvite.config.ts/cypress.config.tssetup.vitestyarn installcannot link it against Vite 7.detect-portutil.debuglog, which breaks the browser bundle (it is imported from front-end code).graphqlgraphql-tools9 and@graphql-tools/*8) — listed here only to note the GraphQL stack moved as one unit.Source impact
axios,react/react-dom,react-number-format,react-virtualized,uuid,clsx,date-fns,formik,yup1,@mui/*5.18,aws-amplify,@okta/*,@auth0/auth0-react,@graphql-tools/*. Backend runtime:express5,passport0.7,morgan,express-session,http-proxy-middleware,connect-history-api-fallback,bcryptjs3,fuse.js7,graphql17.@types/*,cypress,@cypress/code-coverage4,@percy/*,prettier,typescript-eslint,nyc,jsdom,nodemon,concurrently,cross-env,dotenv,wait-on,start-server-and-test,husky,patch-package,npm,babel-loader,@babel/*.src/setupProxy.js(http-proxy-middleware v3),scripts/seedDataUtils.ts(lodash typings),src/components/TransactionCreateStepTwo.tsx(react-number-format v5),backend/auth.ts(passport 0.7 logout),backend/app.ts(Express 5req.query), and prettier 3.9 reformatting insrc/machines/*andsrc/models/notification.ts.Validation
yarn lint(eslint + prettier --check): passyarn types/yarn build(tsc --noEmitthenvite build): passyarn test:unit:ci(vitest): 44 passed, 10 skippedyarn db:seedregenerates seed data successfully with the upgraded faker/lodash stackdevelopwas verified green before any upgrade, and each batch/major was validated independently before it was committedFrontend verification
Recorded browser walkthrough against
yarn dev(Vite on :3000, Express API on :3001) with the seeded database, as the seeded userHeath93:NumericFormatrenders$25, submit →Transaction Submitted!, balance$1,509.53→$1,484.53, and the payment appears first in the MINE feedregenerateerror, no nodemon restart)yarn start:cistarts cleanly on http-proxy-middleware 3; withBACKEND_PORT=3001,/login,/checkAuthand/graphqlproxy to the backend while/and/personalfall back to the SPAFull results, per-check evidence and the verification recording for the backend fixes are in this comment.
Pre-existing console noise unaffected by this PR: React "Invalid DOM property
stop-color" warnings fromsrc/components/SvgCypressLogo.tsx, xstate empty-string-transition deprecation warnings, and HTTP 410s from the retiredavatars.dicebear.comavatar URLs used by the seed data.Pre-existing issue, not fixed here:
src/setupProxy.jsreadsprocess.env.BACKEND_PORT, which is defined nowhere in the repo (.envonly hasVITE_BACKEND_PORT), soyarn start:ciproxies tolocalhost:undefinedand returns 504 unless the variable is supplied.develophas the same bug; worth a separate fix.Link to Devin session: https://app.devin.ai/sessions/5146de38ebb147cfbda93ad807a68c4d
Requested by: @dr-phil
Devin Review