Hi — I’m Chai, the maintainer of Payload Components.
I reviewed supaku/payload-auth-cookie and found an active Payload v3 + Next.js 15/16 setup with an existing block/page-builder structure. That looks close to the projects the registry is built for.
Payload Components is MIT source tooling: it installs a block and wires the Pages collection, renderer mapping, generated Payload types, and admin import map rather than leaving those integration steps manual.
Would a small, repository-specific contribution be useful here? I can add one block that fits an existing page surface and include the collection, renderer, type, and import-map wiring in one reviewable diff.
If this is in scope, which page surface or component family would be most useful? I’ll wait for alignment before opening a larger PR.
Hi — I’m Chai, the maintainer of Payload Components.
I reviewed
supaku/payload-auth-cookieand found an active Payload v3 + Next.js 15/16 setup with an existing block/page-builder structure. That looks close to the projects the registry is built for.Payload Components is MIT source tooling: it installs a block and wires the Pages collection, renderer mapping, generated Payload types, and admin import map rather than leaving those integration steps manual.
Would a small, repository-specific contribution be useful here? I can add one block that fits an existing page surface and include the collection, renderer, type, and import-map wiring in one reviewable diff.
If this is in scope, which page surface or component family would be most useful? I’ll wait for alignment before opening a larger PR.