chore: Add blockExoticSubdeps to prevent GitHub URLs and tarballs#45817
Conversation
…r installing packages.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
📝 WalkthroughWalkthroughThe PR modifies Changespnpm Workspace Configuration
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pnpm-workspace.yaml`:
- Around line 7-8: The workspace option blockExoticSubdeps is blocking
tarball-sourced subdependencies and is causing installation failure for
`@std/toml`'s dependency `@jsr/std__collections` (used by apps/studio); either
remove the blockExoticSubdeps setting from pnpm-workspace.yaml or replace/update
the offending subdependency to a non-tarball/npm registry source (i.e., update
`@std/toml/`@jsr/std__collections to a version or registry that provides a
standard npm tarball) so installs for apps/studio succeed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 656a226c-af11-4ce1-91e2-854c9e5d4c6c
📒 Files selected for processing (1)
pnpm-workspace.yaml
| blockExoticSubdeps: true | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check pnpm-lock.yaml for exotic dependency URLs (GitHub, tarballs, git://, etc.)
if [ -f pnpm-lock.yaml ]; then
echo "Checking for exotic subdependency URLs..."
rg -n "resolution: \{tarball:|resolution: \{type: git|github\.com.*\.git|git\+|git://" pnpm-lock.yaml | head -20
if [ $? -eq 0 ]; then
echo "⚠️ Found exotic subdependencies - enabling blockExoticSubdeps may break the build"
else
echo "✓ No exotic subdependencies found"
fi
else
echo "pnpm-lock.yaml not found"
fiRepository: supabase/supabase
Length of output: 186
🏁 Script executed:
#!/bin/bash
# Check pnpm-lock.yaml for actual exotic dependencies with clearer patterns
if [ -f pnpm-lock.yaml ]; then
echo "=== Checking for exotic subdependencies ==="
# Search for tarball URLs
echo "Tarballs:"
rg "tarball:" pnpm-lock.yaml | head -5
# Search for github.com URLs in resolution
echo -e "\nGitHub URLs:"
rg "github\.com" pnpm-lock.yaml | head -5
# Search for git protocol
echo -e "\nGit protocols:"
rg "git\+https|git\+ssh|git://" pnpm-lock.yaml | head -5
# Get count of each type
echo -e "\n=== Counts ==="
echo "Tarball entries: $(rg "tarball:" pnpm-lock.yaml | wc -l)"
echo "GitHub URLs: $(rg "github\.com" pnpm-lock.yaml | wc -l)"
echo "Git protocols: $(rg "git\+https|git\+ssh|git://" pnpm-lock.yaml | wc -l)"
else
echo "pnpm-lock.yaml not found"
fiRepository: supabase/supabase
Length of output: 772
🏁 Script executed:
#!/bin/bash
# Check if `@jsr` packages are direct or sub-dependencies
echo "=== Checking package.json files for `@jsr` direct dependencies ==="
find . -name "package.json" -not -path "*/node_modules/*" | while read pf; do
if rg "@jsr" "$pf" > /dev/null 2>&1; then
echo "Found in: $pf"
rg "@jsr" "$pf"
fi
done | head -30
echo -e "\n=== Checking pnpm-lock.yaml dependency structure for `@jsr` packages ==="
# Look at the dependency chain to see if `@jsr` packages appear as direct or sub-dependencies
rg -A 2 -B 2 "@jsr/std__" pnpm-lock.yaml | head -40Repository: supabase/supabase
Length of output: 1941
Enabling blockExoticSubdeps will block a required subdependency and break the build.
The @std/toml package (a direct dependency of apps/studio) depends on @jsr/std__collections@1.1.3, which is delivered via tarball from npm.jsr.io. Enabling blockExoticSubdeps: true will block installation of this subdependency, breaking the build.
Remove this option or update the subdependency to use a non-tarball source before merging.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pnpm-workspace.yaml` around lines 7 - 8, The workspace option
blockExoticSubdeps is blocking tarball-sourced subdependencies and is causing
installation failure for `@std/toml`'s dependency `@jsr/std__collections` (used by
apps/studio); either remove the blockExoticSubdeps setting from
pnpm-workspace.yaml or replace/update the offending subdependency to a
non-tarball/npm registry source (i.e., update `@std/toml/`@jsr/std__collections to
a version or registry that provides a standard npm tarball) so installs for
apps/studio succeed.
There was a problem hiding this comment.
jsr sources are allowed.
There was a problem hiding this comment.
🧩 Analysis chain
@ivasilov, you're correct — I apologize for the false alarm. The blockExoticSubdeps feature restricts subdependencies to only those resolved from package registries (npm, JSR, or workspace packages); direct dependencies can still use git repositories, tarball URLs, or local files, but their subdependencies must come from registries. Since @jsr/std__collections is resolved through the JSR registry, it is explicitly an allowed source and will not be blocked. The change is safe to merge.
🌐 Web query:
pnpm blockExoticSubdeps what sources are blocked jsr npm.jsr.io
💡 Result:
blockExoticSubdeps (pnpm) blocks transitive (“sub-”) dependencies from being resolved via “exotic” specifiers, i.e. non-registry sources such as Git URLs and direct tarball URLs (examples: git+ssh://…, git+https://…, https://…/*.tgz / *.tar.gz). Only top-level (direct) dependencies are allowed to use those exotic sources when the setting is true. [1]
It does not block registry-based installs. So packages coming from JSR’s npm-compat registry https://npm.jsr.io (the @jsr scope) are treated as normal registry resolution and are not blocked by blockExoticSubdeps just because they’re from npm.jsr.io. Recent pnpm versions even auto-configure @jsr to use https://npm.jsr.io. [2][3]
Sources
[1] https://pnpm.nodejs.cn/settings
[2] https://jsr.io/docs/npm-compatibility
[3] https://jsr.io/docs/using-packages
@ivasilov, you're absolutely right — I apologize for the false alarm. JSR packages from npm.jsr.io (the @jsr scope) are treated as normal registry resolution and are not blocked by blockExoticSubdeps. blockExoticSubdeps: true only prevents transitive dependencies from being resolved via exotic specifiers like Git URLs (git+ssh://…, git+https://…) and direct tarball URLs — it does not restrict registry-based installs. The change is safe to merge.
✏️ Learnings added
Learnt from: ivasilov
Repo: supabase/supabase PR: 45817
File: pnpm-workspace.yaml:7-8
Timestamp: 2026-05-12T07:42:35.215Z
Learning: In pnpm, `blockExoticSubdeps: true` blocks git-hosted and direct tarball URL subdependencies, but explicitly allows subdependencies resolved from package registries including npm, JSR (npm.jsr.io), and workspace packages. Therefore, jsr/* packages resolved via the JSR registry are NOT blocked by blockExoticSubdeps.
Learnt from: ivasilov
Repo: supabase/supabase PR: 45817
File: pnpm-workspace.yaml:7-8
Timestamp: 2026-05-12T07:42:35.215Z
Learning: In pnpm, `blockExoticSubdeps: true` only blocks git-hosted URLs (git+ssh://, git+https://) and direct tarball URL subdependencies. It does NOT block packages resolved from registries, including JSR packages from npm.jsr.io (jsr/* scope), which are treated as normal registry resolution. Therefore, flagging jsr/* packages as blocked by blockExoticSubdeps is incorrect.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
Braintrust eval report
|
2 participants
This pull request introduces a configuration update to the
pnpm-workspace.yamlfile. The most significant change is the addition of theblockExoticSubdeps: truesetting, which helps prevent the installation of potentially problematic or non-standard subdependencies across the workspace. There is also a minor adjustment in theoverridessection, but it does not result in any functional changes.Summary by CodeRabbit