# Fulldev UI: a shadcn-compatible component registry for Astro, React and Liquid

> Fulldev UI publishes its components through the shadcn registry system rather than as an importable library, so the code lands in your repository and you own it. The interesting part is the range it covers, from pure Astro components to a native Shopify Liquid path with no theme build step, and the container-query requirement that catches people out.

**fulldotdev/ui** — Components and Blocks for building content-driven Astro websites

- Repository: https://github.com/fulldotdev/ui
- Website: https://ui.full.dev
- Stars: 614 · Forks: 32
- Language: Astro
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/fulldotdev-ui

## The npm package ships a registry, not a library

The single most important thing to understand about Fulldev UI is what you actually install.

The README describes it as a shadcn-compatible UI library for Astro, React and native Shopify Liquid, and the feature list leads with vanilla Astro components with no framework dependencies, pure Astro components, and shadcn compatibility through the shadcn CLI and registry system.

But the npm package section says something more precise. The `fulldev-ui` package holds the registry of each release, with no code to import and no dependencies. The `public/r` directory has the files served at `https://ui.full.dev/r`, and `liquid/` holds the native Liquid files at their theme paths. You install components with the shadcn CLI, and the package keeps every release available as a versioned copy.

So the delivery model is copy the source into your repository. There is no `import { Button } from 'fulldev-ui'` and no node_modules entry to bump. The package on npm is the distribution channel for the registry files, the way shadcn's own registry works, and the consequence is that updating a component means re-running the add command and reviewing a diff, exactly like shadcn itself.

That is a deliberate trade. You get to edit the component, you get no runtime dependency, and you get no automatic upgrades. The manifest confirms the shape: the `files` array is `CHANGELOG.md`, `LICENCE`, `README.md`, `public/r` and `liquid`, and the package is not marked `sideEffects` or `private`, so it is published publicly under `publishConfig` with public access.

The project is MIT licensed, copyright Fulldev 2024 to present, the repository is not archived, and the last push was on 2026-10-22, and the three most recent releases are 0.25.2 on 2026-10-18 followed by 0.25.3 and 0.25.4 on 2026-10-19.

## Installation is the shadcn CLI, and the app shell needs a container

The quick start is a five-step path, and step 4 is the one that trips people up.

Step one is creating an Astro project if you do not have one:

```bash
npx create-astro@latest my-project --template with-tailwindcss --install --git
cd my-project
```

Step two is the TypeScript path alias in `tsconfig.json`:

```json
{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}
```

Step three initializes the registry with the shadcn CLI, and this is where the theme comes in:

```bash
npx shadcn@latest init https://ui.full.dev/r/styles/base-vega/base.json
```

The README says to replace `base-vega` with another shadcn/ui style, such as `base-nova`, and points to the presets documentation for the shadcn/ui options.

Step four is the container-aware app shell, and the reason is spelled out. Fulldev UI uses Tailwind v4 container-query variants like `@2xl:` and `@max-5xl:`, which means the components size themselves against their container rather than the viewport. Without a container on the body, those variants never apply.

```astro
---
import "@/styles/global.css"
---

<body class="@container">
  <slot />
</body>
```

Step five adds a component:

```bash
npx shadcn@latest add @fulldev/button
```

The prerequisite is Node.js 22.12.0 or newer.

## The container-query requirement changes how you compose the layout

The `@container` class is worth more attention than it first appears, because it is a different layout model rather than a missing class.

With Tailwind v3 and earlier, responsive variants were viewport based. A component that says `md:grid-cols-3` reacts to the browser window. The Tailwind v4 container-query variants that Fulldev UI uses, `@2xl:` and `@max-5xl:`, react to the size of the element's own container instead. A block placed in a narrow sidebar stays narrow, and a section placed in a wide main column fills it, regardless of how wide the window happens to be.

For a content-driven marketing site that is the right choice, because the same block appears in a full-width hero, in a two-thirds column beside a sidebar, and in a card, and all three need different internal proportions. But it means the ancestor element has to be a query container, and the README is explicit that this is why the app shell needs the class.

The consequence for an adopter is that if you skip step four, the blocks will not error out. They will simply lay out as if they were in a container of unknown or zero width, which usually means the wrong column count. That is a quietly wrong result rather than a broken page, which is the harder kind to notice.

The Astro side has a further property that the feature list leads with. The components are pure Astro with no framework dependencies, so a site that is entirely static does not ship a React runtime for the sake of a button. The React extension is described separately, as the Fulldev extras and blocks for official shadcn/ui React projects, which is the path to take when you want the same design in a React-rendered part of the site.

## Native Shopify Liquid ships without a theme build step

The Liquid path is the least conventional part of the project and the one with the clearest technical claim.

The README says you can install into a Shopify theme with `npx shadcn@latest add https://ui.full.dev/r/liquid/components.json`, then render `ui` once in the layout head. The result is described as readable CSS, native ES modules and shared tokens, with no theme build step.

That last phrase is the whole point. A Shopify theme is not a build pipeline. There is no bundler, no npm install inside the theme, and no compile step to run before the theme can be uploaded. A component library that assumes one cannot be used at all, so shipping plain CSS and ES modules is what makes the library reachable from a theme at all.

The `liquid/` directory in the package manifest is where those files live, and it is listed in the `files` array, so the Liquid assets ship in the same npm package as the Astro registry files. There is a separate `liquid/README.md` and a dedicated Liquid section in the documentation.

The repository backs this up with real tooling. The `check` script runs `node scripts/liquid-theme-check.mjs` alongside the other checks, and the package imports map includes `#liquid-fixture` pointing at `./tests/helpers/liquid.mjs`, which suggests the Liquid output is verified in tests against a fixture theme rather than only documented.

The trade-off is obvious but worth stating. Supporting three rendering targets, Astro, React and Liquid, means each component exists in more than one form, and the component library is described as having 100 plus components and blocks, so the surface to keep consistent across those targets is large.

## Content-first is a positioning choice, not a technical one

The feature list describes the library as content-first, built for content-driven websites with components like sections, typography and prices. That sentence tells you what kind of project this is aimed at and, just as usefully, what it is not.

There are no primitives in the usual sense. No button, input, dialog, dropdown or table as the core of the library. Instead there are sections, which are whole page regions, typography, and prices, which is a specific content type. The components and blocks are described as ready-to-use UI components and pre-built page blocks, and the topics list includes both astro-components and astro-blocks and pagebuilder.

So the unit of adoption is a section of a landing page rather than a widget you drop into your own layout. That is a coherent choice for agencies and for anyone who ships marketing pages repeatedly, and it is why a 100 component count is plausible in a library that does not include a select element.

The other feature list items are worth noting for what they promise. The Tailwind CSS v4 styling and full TypeScript support are the baseline expectations for a component library in 2026, and the fact that they are called out is more informative about the audience than about the features. The 100 plus components and blocks figure is the number to look at when deciding whether the library covers your page types.

The npm package also holds the registry of each release, and the `public/r` path is what the shadcn CLI fetches. The `registry.json` and `registry/` files at the top level are the source of that served content, and the repository keeps a `CHANGELOG.md` and a `.changeset/` directory, so the registry is regenerated and versioned rather than edited by hand.

## The check pipeline enforces that the committed registry matches a fresh build

The development section documents a check pipeline that is more thorough than most component libraries run, and one of its rules is specific enough to be worth quoting.

Development requires Node 24 from the `.node-version` file, pnpm 12 and Vite+ (`vp`), which runs the scripts locally and in CI. Installs never run dependency or project lifecycle scripts, configured in `pnpm-workspace.yaml`.

```bash
pnpm install         # frozen lockfile in CI and on Netlify
pnpm dev             # docs site at http://127.0.0.1:4321
vp run build         # builds the docs and the React previews
vp run check  # the source checks every Ready PR runs
vp run test:unit     # the tests in tests, which Ready PRs also run
vp run fix    # Prettier and ESLint fixes
pnpm images          # converts source photos in src to WebP
pnpm ui:add @shadcn/card  # installs with the shadcn CLI, then runs Prettier
pnpm registry:build  # regenerates public/r after registry changes
```

`vp run check` runs Prettier, TypeScript and `astro check`, ESLint, knip, the source photo check, and, specific to this registry, `registry:check`, where the committed `public/r` must match a fresh build. That last one closes the loop that most copy-in libraries leave open: the served registry files are a build artifact, and the build is verified against what is committed.

The manifest confirms the same list at the script level. The `check` script is `prettier --check . && pnpm typecheck && eslint . && knip && node scripts/images.ts --check && node scripts/liquid-theme-check.mjs && pnpm registry:check`, and the typecheck itself is a compound of `tsc --noEmit --noCheck`, `astro check --minimumFailingSeverity hint` and a separate `tsc --noEmit -p react` for the React side. The unit tests run with the Node built-in test runner over `tests/*.test.mjs`.

There is also a `pnpm ui:add` wrapper that runs the shadcn CLI and then formats, and the README explains why: a plain `pnpm dlx shadcn@latest add` leaves the CLI's own formatting, which the next format run may change, so a later `vp run fix` or `vp run check` would show a diff in files you did not touch.

Two extras round it out. The `og` script regenerates per-page Open Graph screenshots in `public/og/` with Playwright's Chromium, controllable with `CHROME` and `OG_PORT`, and the README notes the normal build checks image coverage and dimensions without launching a browser. And for coding agents there are skills to install, `npx skills add shadcn/ui` and `npx skills add fulldotdev/ui --skill fulldev-ui`.

## Conclusion

Adopt Fulldev UI if you build content-driven Astro sites and want blocks that assume a marketing page shape, sections, typography and prices, rather than generic primitives, and you are willing to own the copied component code. Do not adopt it if you want a versioned dependency you can upgrade with a package manager, since the npm package carries no importable code and no dependencies, only the registry. Verify first that your app shell carries the `@container` class, because the components rely on Tailwind v4 container-query variants and will size incorrectly without it.

## FAQ

### How do I install Fulldev UI in an Astro project?

Add the library with `npx shadcn@latest init https://ui.full.dev/r/styles/base-vega/base.json`, then add individual components with `npx shadcn@latest add @fulldev/button`. The README also requires Node.js 22.12.0 or newer and a `@container` class on the body element.

### Why does the Fulldev UI app shell need the @container class?

Because Fulldev UI uses Tailwind v4 container-query variants like `@2xl:` and `@max-5xl:`, which size a component against its container rather than the viewport. The README instructs adding the class to the body, and the components will size incorrectly without it.

### Can I use Fulldev UI in a Shopify theme?

Yes. Install with `npx shadcn@latest add https://ui.full.dev/r/liquid/components.json` and render `ui` once in the layout head. The README describes the result as readable CSS, native ES modules and shared tokens, with no theme build step.

### Does the fulldev-ui npm package contain code I import?

No. The README says the package holds the registry of each release, with no code to import and no dependencies. The public/r directory holds the files served at the registry URL and liquid/ holds the native Liquid files, and components are installed into your project with the shadcn CLI.

### What does Fulldev UI contain, and who is it for?

The feature list describes 100 plus components and blocks, built for content-driven websites with components like sections, typography and prices, styled with Tailwind CSS v4 and typed with TypeScript. It ships as vanilla Astro components, a React extension for shadcn/ui React projects, and native Shopify Liquid files.

## Sources

- [fulldotdev/ui on GitHub](https://github.com/fulldotdev/ui)
- [License: MIT](https://github.com/fulldotdev/ui/blob/main/LICENSE)
- [Project website](https://ui.full.dev)
- [README](https://github.com/fulldotdev/ui/blob/main/README.md)
- [Releases](https://github.com/fulldotdev/ui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fulldotdev-ui