feat: Shadcn Registry Package

[I-3B]

closes #1022 #1036 #1118

Checklist

• Registry package
• parseAsTuple registry item
• unit tests for parseAsTuple
• add usage .md for parseAsTuple

[vercel]

@I-3B is attempting to deploy a commit to the 47ng Team on Vercel.

A member of the Team first needs to authorize it.

[franky47]

Thanks! I was working on the docs part (listing of installable items and copy/paste vs CLI methods) while on the plane, I'll open a PR later today.

[I-3B]

hi @franky47 !
this is still WIP, but would like your opinion on exposing lib/ like this
also I'm not entirely sure about the trusted registry part, do we need to submit anything to shadcn?

[franky47]

Yeah I'll open a PR to the shadcn registry, as we have the green light from the man himself, but once #1189 is live.

I have opened #1189 as a draft too for the docs UI part, we could stack yours on top of that one to add parseAsTuple.

At a first glance, I'm not super keen on widening the exported API for internal purposes, I'll have to take a closer look once I'm home. But in #1189 I have all the "sources" for the registry as part of where it is deployed (in the docs package), and that causes problems in terms of dependencies, so a separate package might make more sense.

Like I wanted to add the equivalent of the next-typed-links snippet for React Router's href utility, but that would have implied adding the react-router dependency to the docs, along with tests harnesses etc.. Better do a separate package, have it build the registry JSON files and mark it as a dependency of the docs. We'll still need to copy the built output into the docs' public/r directory (having root level item URLs might clash and the trusted registry mapping makes the /r/ subpath invisible anyway) before build starts (as the registry docs page read those files to populate its content).

[I-3B]

At a first glance, I'm not super keen on widening the exported API for internal purposes

agree, alternative is to add a lib/utils.ts (like shdacn's cn function), but didn't go that way cause it will mean there will be two copies of this util to maintain (which i think is okay, it's not a big function anyway)

[I-3B]

I didn't add debug file as I thought it's an internal package detail that shouldn't be put in users' files, tradeoff of course is that debug flag doesn't work with community parsers

[franky47]

I merged #1189, feel free to rebase on top of that.

It might make sense to expose the safeParse function as initially suggested (which would also make the feat: prefix a legitimate minor bump for the nuqs package).

[franky47]

note: This would also need to install the safeParse utility as it's used in the parseAsTuple file.

Maybe it would make sense to export it from nuqs then, as it's useful for custom parsers anyway.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
nuqs	Ready	Preview	Comment	Oct 28, 2025 10:06am