Conversation
The following vulnerabilities are fixed with an upgrade: - https://snyk.io/vuln/SNYK-JS-LODASH-15869619 - https://snyk.io/vuln/SNYK-JS-LODASH-15869625 - https://snyk.io/vuln/SNYK-JS-XMLDOMXMLDOM-15869636
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
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.
| "@tamagui/animations-moti": "1.108.0", | ||
| "@tamagui/config": "1.108.0", | ||
| "@tamagui/static": "1.108.0", | ||
| "@tamagui/static": "1.129.6", |
There was a problem hiding this comment.
Tamagui package version mismatch breaks compatibility
High Severity
@tamagui/static is bumped to 1.129.6 while all other @tamagui/* packages (animations-moti, config, themes, toast, babel-plugin) remain pinned at 1.108.0. Tamagui's own documentation states that "99% of the time" configuration errors are "due to having mis-matched versions of Tamagui dependencies" and that every @tamagui/* dependency must be pinned to exactly the same version. This mismatch is very likely to cause build or runtime failures.
Additional Locations (1)
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b8129abee1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "@tamagui/animations-moti": "1.108.0", | ||
| "@tamagui/config": "1.108.0", | ||
| "@tamagui/static": "1.108.0", | ||
| "@tamagui/static": "1.129.6", |
There was a problem hiding this comment.
Commit yarn.lock with this dependency version change
This change updates direct dependency versions in package.json but does not include the corresponding yarn.lock update, which will break installs in CI because this repo runs immutable installs (for example .github/workflows/lint.yml and .github/workflows/unittest.yml both execute yarn install --immutable). With the new descriptor @tamagui/static@1.129.6 missing from lockfile, immutable install fails and the security fix cannot be reliably applied.
Useful? React with 👍 / 👎.
| "@tamagui/animations-moti": "1.108.0", | ||
| "@tamagui/config": "1.108.0", | ||
| "@tamagui/static": "1.108.0", | ||
| "@tamagui/static": "1.129.6", |
There was a problem hiding this comment.
🔴 @tamagui/static bumped to 1.129.6 while all other tamagui packages remain at 1.108.0
The PR bumps @tamagui/static from 1.108.0 to 1.129.6, but every other tamagui package in the monorepo remains pinned at 1.108.0: @tamagui/animations-moti, @tamagui/config, @tamagui/themes, @tamagui/toast, tamagui, @tamagui/babel-plugin (line 261), and tamagui-loader (line 351). The tamagui ecosystem expects all packages to be at the same version. Notably, tamagui-loader@1.108.0 declares its own dependency on @tamagui/static@1.108.0 (confirmed in yarn.lock), so the root-level bump to 1.129.6 introduces a second copy of the package without actually replacing the version used by the loader. This 21-minor-version gap can cause build-time failures or silent static-extraction mismatches if both versions are loaded, and the transitive vulnerable version (1.108.0) used by tamagui-loader remains unfixed.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "@supabase/supabase-js": "^2.77.0", | ||
| "@tamagui/animations-moti": "1.108.0", | ||
| "@tamagui/config": "1.108.0", | ||
| "@tamagui/static": "1.108.0", | ||
| "@tamagui/static": "1.129.6", |
There was a problem hiding this comment.
🔴 yarn.lock not updated — vulnerability fixes are ineffective
The package.json changes @expo/plist from ^0.1.3 to ^0.3.0 and @tamagui/static from 1.108.0 to 1.129.6, but the yarn.lock was not regenerated. The lockfile still resolves @expo/plist via the ^0.1.3 specifier to 0.1.3 (which depends on vulnerable @xmldom/xmldom ~0.7.7) and @tamagui/static to 1.108.0 (with vulnerable lodash). Running yarn install --immutable in CI will fail because the lockfile doesn't satisfy the new package.json constraints. Until the lockfile is updated, the stated vulnerability fixes (SNYK-JS-XMLDOMXMLDOM, SNYK-JS-LODASH) are not actually applied.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "@cityofzion/neon-core": "^5.7.0", | ||
| "@cowprotocol/contracts": "^1.7.0", | ||
| "@expo/plist": "^0.1.3", | ||
| "@expo/plist": "^0.3.0", |
There was a problem hiding this comment.
🔴 yarn.lock not updated for @expo/plist version bump — security fix is ineffective
The package.json changes @expo/plist from ^0.1.3 to ^0.3.0, but yarn.lock was not regenerated. The root workspace entry in yarn.lock:9192 still references npm:^0.1.3, and the resolution at yarn.lock:5656 still resolves to 0.1.3. There is no ^0.3.0 resolution entry in the lockfile. This means the vulnerable version 0.1.3 will continue to be installed, making this security fix completely ineffective.
Prompt for agents
The yarn.lock file was not updated after bumping @expo/plist from ^0.1.3 to ^0.3.0 in package.json. Run `yarn install` to regenerate the lockfile so it resolves the new version. Verify the resolved version is >= 0.3.0 in the updated lockfile.
Was this helpful? React with 👍 or 👎 to provide feedback.


Snyk has created this PR to fix 3 vulnerabilities in the yarn dependencies of this project.
Snyk changed the following file(s):
package.jsonNote for zero-installs users
If you are using the Yarn feature zero-installs that was introduced in Yarn V2, note that this PR does not update the
.yarn/cache/directory meaning this code cannot be pulled and immediately developed on as one would expect for a zero-install project - you will need to runyarnto update the contents of the./yarn/cachedirectory.If you are not using zero-install you can ignore this as your flow should likely be unchanged.
Vulnerabilities that will be fixed with an upgrade:
SNYK-JS-LODASH-15869619
SNYK-JS-LODASH-15869625
SNYK-JS-XMLDOMXMLDOM-15869636
Important
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic
Learn how to fix vulnerabilities with free interactive lessons:
🦉 Prototype Pollution
🦉 Arbitrary Code Injection
🦉 XML Injection
Note
Medium Risk
Dependency upgrades can introduce build/runtime regressions, especially with the larger
@tamagui/staticversion jump; PR also doesn’t include ayarn.lockupdate so resolved versions may differ until regenerated.Overview
Updates
package.jsonto remediate reported Snyk issues by bumping dependencies:@expo/plistfrom^0.1.3to^0.3.0and@tamagui/staticfrom1.108.0to1.129.6.Written by Cursor Bugbot for commit b8129ab. This will update automatically on new commits. Configure here.