feat: add github registry support#409
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR adds Shadcn registry configuration and validation, updates React registry generation and entries for core version 3.0.2, adds a unified release tag, and includes deprecation metadata in JSON API responses. ChangesShadcn React registry
API deprecation metadata
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Generator as generate-registry.mjs
participant Registry as packages/react/registry.json
participant CI as ci-cd.yml
participant Release as publish-public-npm.yml
Generator->>Registry: generate React registry entries
CI->>Registry: regenerate and validate registry
Release->>Release: create and push v${VERSION} tag
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
harishsundar-okta
changed the title
🚀 Preview deploymentBranch: 📝 Preview URL: https://auth0-universal-components-o1jo7lt0y-ui-components-217de888.vercel.app Updated at 2026-07-27T12:45:13.439Z |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #409 +/- ##
=======================================
Coverage 89.80% 89.80%
=======================================
Files 236 236
Lines 17632 17632
Branches 2019 2019
=======================================
Hits 15835 15835
Misses 1797 1797 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
rax7389
left a comment
rax7389
left a comment
There was a problem hiding this comment.
Please resolve the conflicts
|
@coderabbitai Review the PR changes |
|
It installs ✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 @.github/workflows/ci-cd.yml:
- Around line 57-58: Update the “Validate shadcn registry” workflow step to
invoke a reviewed, fixed shadcn release instead of the mutable latest tag, and
restrict the job’s token permissions to contents: read. Keep the existing
registry validation command and apply the permission setting at the job scope.
In @.github/workflows/publish-public-npm.yml:
- Around line 311-322: Update the release-tag flow around UNIFIED_TAG to
preserve tag immutability: remove the local and remote deletion logic, check
whether the tag already exists remotely, and fail the workflow before creating
or pushing it. Continue creating and pushing the tag only when it does not
already exist.
In `@docs-site/api/r.ts`:
- Around line 79-80: Update the deprecation headers in the response setup:
change the Deprecation value to an RFC 9745 date format using the applicable
Unix timestamp, and correct the Sunset header’s weekday from Sat to Thu while
preserving its intended date and time.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 9f142a53-94c4-4095-96b2-6921f7da3464
📒 Files selected for processing (6)
.github/workflows/ci-cd.yml.github/workflows/publish-public-npm.ymldocs-site/api/r.tspackages/react/registry.jsonpackages/react/scripts/generate-registry.mjsregistry.json
| if git rev-parse "$UNIFIED_TAG" >/dev/null 2>&1; then | ||
| echo "Tag $UNIFIED_TAG exists locally, deleting..." | ||
| git tag -d "$UNIFIED_TAG" | ||
| fi | ||
|
|
||
| if git ls-remote --tags origin | grep -q "refs/tags/$UNIFIED_TAG"; then | ||
| echo "Tag $UNIFIED_TAG exists remotely, deleting..." | ||
| git push origin ":refs/tags/$UNIFIED_TAG" || true | ||
| fi | ||
|
|
||
| git tag -a "$UNIFIED_TAG" -m "Release v${VERSION} — GitHub Registry ref" | ||
| git push origin "$UNIFIED_TAG" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Keep GitHub Registry version tags immutable.
Deleting and recreating v${VERSION} can make the same installation ref resolve to different source. Fail if the release tag already exists instead of moving it.
Proposed fix
- if git rev-parse "$UNIFIED_TAG" >/dev/null 2>&1; then
- echo "Tag $UNIFIED_TAG exists locally, deleting..."
- git tag -d "$UNIFIED_TAG"
- fi
-
- if git ls-remote --tags origin | grep -q "refs/tags/$UNIFIED_TAG"; then
- echo "Tag $UNIFIED_TAG exists remotely, deleting..."
- git push origin ":refs/tags/$UNIFIED_TAG" || true
+ if git rev-parse "$UNIFIED_TAG" >/dev/null 2>&1 ||
+ git ls-remote --exit-code --tags origin "refs/tags/$UNIFIED_TAG" >/dev/null 2>&1; then
+ echo "::error::Release tag $UNIFIED_TAG already exists; refusing to move it."
+ exit 1
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if git rev-parse "$UNIFIED_TAG" >/dev/null 2>&1; then | |
| echo "Tag $UNIFIED_TAG exists locally, deleting..." | |
| git tag -d "$UNIFIED_TAG" | |
| fi | |
| if git ls-remote --tags origin | grep -q "refs/tags/$UNIFIED_TAG"; then | |
| echo "Tag $UNIFIED_TAG exists remotely, deleting..." | |
| git push origin ":refs/tags/$UNIFIED_TAG" || true | |
| fi | |
| git tag -a "$UNIFIED_TAG" -m "Release v${VERSION} — GitHub Registry ref" | |
| git push origin "$UNIFIED_TAG" | |
| if git rev-parse "$UNIFIED_TAG" >/dev/null 2>&1 || | |
| git ls-remote --exit-code --tags origin "refs/tags/$UNIFIED_TAG" >/dev/null 2>&1; then | |
| echo "::error::Release tag $UNIFIED_TAG already exists; refusing to move it." | |
| exit 1 | |
| fi | |
| git tag -a "$UNIFIED_TAG" -m "Release v${VERSION} — GitHub Registry ref" | |
| git push origin "$UNIFIED_TAG" |
🤖 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 @.github/workflows/publish-public-npm.yml around lines 311 - 322, Update the
release-tag flow around UNIFIED_TAG to preserve tag immutability: remove the
local and remote deletion logic, check whether the tag already exists remotely,
and fail the workflow before creating or pushing it. Continue creating and
pushing the tag only when it does not already exist.
There was a problem hiding this comment.
Intentional design — the delete-and-recreate behavior is needed because our publish workflow can be re-run on failure (e.g. partial npm publish). If the tag were immutable, a retry after a transient failure would require manual tag cleanup before the workflow could succeed. Since the tag always points to the same commit within a single workflow run, consumers installing by tag still get deterministic resolution for any given release.
There was a problem hiding this comment.
The PR description image shows a dark terminal running:
npx shadcn add auth0/auth0-ui-components/react/my-account/user-mfa-management#feat/github-registry-hybrid
It installs shadcn@4.13.0, reports successful registry and dependency checks, confirms overwriting button.tsx and utils.ts, and lists “Created 60 files”, including src/components/auth/my-account/user-mfa-management.tsx and multiple MFA-related components.
@harishsundar-okta, thanks for clarifying the retry requirement. I agree that avoiding manual cleanup after a failed release is valuable.
However, a rerun is not necessarily the same workflow run or the same commit: workflow_dispatch may be invoked from a different ref, while retaining the same package version. The current delete-and-recreate flow would then move v${VERSION}, so consumers using that tag could receive different registry content over time.
The finding therefore still applies as an intentional tradeoff rather than an accidental behavior. If mutable tags are the accepted release policy, no change is needed here; documenting that policy near this block would help make the consumer-facing contract explicit.
✏️ Learnings added
Learnt from: harishsundar-okta
Repo: auth0/auth0-ui-components PR: 409
File: .github/workflows/publish-public-npm.yml:311-322
Timestamp: 2026-07-27T10:26:18.285Z
Learning: In `.github/workflows/publish-public-npm.yml`, the unified `v${VERSION}` Git tag is intentionally deleted and recreated to support rerunning a failed public NPM publish workflow without manual tag cleanup. This intentionally trades release-tag immutability for retry convenience.
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.
|
|
||
| return { | ||
| name: blockName, | ||
| name: `react/${blockName}`, |
There was a problem hiding this comment.
@harishsundar-okta
The recent generator updates (adding the react/ prefix, framework metadata, and 3.0.1 version bumps) aren't reflected in the checked-in packages/react/registry.json yet.
Before merging, can you:
- Regenerate and commit the updated catalog.
- Add a CI drift check that runs the generator and fails if
registry.jsonchanges. This will keep the catalog and generator perfectly in sync going forward. - Test the release command from a clean consumer project to make sure it works as expected.
There was a problem hiding this comment.
Done — regenerated registry.json and added a CI drift check that runs the generator and fails if the catalog is stale. Will test the install command from a clean consumer project separately.
4 participants
Summary
Implement shadcn GitHub Registries as the primary distribution path for new consumers (hybrid Option 2 from the RAPID), while keeping the Vercel-hosted registry as a backwards-compatible fallback.
Why
shadcn released GitHub Registries (June 2026) which allows any public repo with a registry.json to be directly installable — no server, no build step, no custom URL configuration. This simplifies consumer DX significantly while letting us maintain backwards compatibility for existing consumers.
What
npx shadcn add auth0/auth0-ui-components/react/my-account/user-mfa-management#v3.0.0Packages
References
Testing
Checklist
Contributing
Summary by CodeRabbit
registry.json.v{VERSION}Git tag.