@nimmervoll/kit

The versioned half of registry.nimmervoll.work.

Most of that registry is copy-in: shadcn add writes a file into your tree and it is yours from then on, to edit and to keep. That is the right model for a CI workflow or a Biome preset — config you are going to change anyway.

It is the wrong model for the handful of items that are not template text but a library: they have an API you bind to, and in one case two files that have to agree with each other. Those are published here as well, so you can take a version you upgrade instead of a copy that ages in place.

Install

bun add @nimmervoll/kit

Zero runtime dependencies — the published modules touch nothing but node:crypto.

Import paths

Subpaths mirror the registry: @nimmervoll/kit/<domain>/<item>.

| Import | Registry item | | --- | --- | | @nimmervoll/kit/aws/access-gate | @nimmervoll/access-gate | | @nimmervoll/kit/tooling/access-gate-e2e | @nimmervoll/access-gate-e2e |

There is deliberately no root export. A barrel would make one import of the Playwright helper pull the CloudFront builder in behind it, and the subpaths are the grouping the items already have.

Which channel do I want?

Take the package when you want the gate to stay current — a fix to the edge function arrives with a version bump, and the e2e helper is guaranteed to derive its cookie through the same code the edge does, because it imports it.

// sst.config.ts
import { createAccessGateInjection } from '@nimmervoll/kit/aws/access-gate'

// playwright.config.ts
import { createAccessGateStorageState } from '@nimmervoll/kit/tooling/access-gate-e2e'

Take the registry when you want the source in your repo to read and change — a gate whose login page you are restyling, or an infra module you are about to fork anyway:

bunx shadcn@latest add @nimmervoll/access-gate

Both ship the same code. The package is generated from the registry's own files, and CI fails when the two disagree, so the choice is about how you want to receive updates and nothing else.

One difference worth knowing: installed from the registry, the e2e helper finds the gate through a relative path into infra/lib/utils/, which you adjust by hand if your suite lives somewhere else. Imported from the package, there is no path to adjust.

Note for the cookie mode

access.html is a file, not a module, so it is not in this package — the cookie mode needs it served at your site root. Either add the registry item alongside (bunx shadcn@latest add @nimmervoll/access-gate) and keep only that page, or use basic mode, which needs no page at all.

Source

Every module here is generated from domains/<domain>/files/ in the registry repo. Fixes go to the domain file; this package is regenerated from it.