UI Framework Integrations

Purpose and Scope

Astro’s UI framework integrations let a project use framework components inside Astro pages, layouts, and components while keeping Astro’s default output lightweight. The official docs describe this as building Astro islands with frameworks such as React, Preact, Svelte, Vue, SolidJS, and AlpineJS. In practice, an integration is the bridge between a framework’s component model and Astro’s renderer pipeline, so authors can import a component from src/components and render it next to Astro components, HTML, and JSX-like template expressions.

This page groups the front-end framework integrations as a family and explains how they fit beside the other official integrations in the repository. The supplied source evidence directly includes the AlpineJS build configuration and several adapter or content-integration build configurations. That makes the most reliable repository-level story the shared package architecture: official integrations are workspace packages, they build against the core astro package, and they are tested and released through the same root scripts that cover @astrojs/*. Sources: README.md, package.json, packages/integrations/alpinejs/tsconfig.build.json

Relevant Source Files

packages/integrations/alpinejs/tsconfig.build.json — shows the AlpineJS integration as an official integration package that extends the shared build TypeScript configuration and references the core astro project.
packages/integrations/cloudflare/tsconfig.build.json — provides a comparison point for adapter integrations, including virtual types and dependencies on internal helpers and redirects support.
packages/integrations/markdoc/tsconfig.build.json — provides a comparison point for content integrations that depend on Astro core, internal helpers, Markdown remark support, and astro-prism.
packages/integrations/mdx/tsconfig.build.json — provides a comparison point for MDX as a content integration that depends on Astro core, internal helpers, remark, and Satteri support.
packages/integrations/netlify/tsconfig.build.json — provides a comparison point for deployment integrations that include source and virtual type declarations and share redirects support.
packages/integrations/node/tsconfig.build.json — provides a comparison point for server runtime adapter integrations that build against Astro core and internal helpers.
README.md — lists official packages in the repository directory, including front-end integrations such as @astrojs/react, @astrojs/preact, @astrojs/solid-js, @astrojs/svelte, and @astrojs/vue.
package.json — defines workspace, build, dev, test, typecheck, and release scripts that include @astrojs/* packages as a group.

Official Front-End Integration Family

The official docs distinguish front-end framework integrations from adapters and other feature integrations. Front-end integrations unlock renderers for UI frameworks; adapters enable server rendering for deployment targets; content and utility integrations add features such as MDX, Markdoc, Partytown, or sitemap generation. The repository README mirrors that product shape by listing individual @astrojs/* packages, including the major UI renderer packages, alongside adapters and other integrations in the package directory. Sources: README.md

For application authors, the important distinction is that a UI framework integration changes how components are authored and rendered, not where routes live. A React, Vue, Svelte, Solid, Preact, or AlpineJS component can be imported into an .astro file and used in the template. By default, framework components render to static HTML on the server, which avoids shipping unnecessary client JavaScript. Interactivity is added deliberately through Astro’s client directives, so the integration supports islands rather than turning the whole page into a client-rendered application.

The supplied repository build metadata shows AlpineJS as the directly represented UI framework integration in this page’s source set. Its tsconfig.build.json extends the shared repository build configuration and references ../../astro/tsconfig.json, which is the core dependency all official integrations need when compiling against Astro’s public integration and renderer surfaces. This keeps the package in the same TypeScript project-reference graph as the framework itself instead of treating it as an external example. Sources: packages/integrations/alpinejs/tsconfig.build.json

System-to-Code Mapping

Integration category	User-facing purpose	Source signal in this page
Front-end renderer	Use framework components as Astro islands	`packages/integrations/alpinejs/tsconfig.build.json` references Astro core
Deployment adapter	Enable server output for a hosting/runtime target	`packages/integrations/cloudflare/tsconfig.build.json`, `packages/integrations/netlify/tsconfig.build.json`, and `packages/integrations/node/tsconfig.build.json` include `./src` and `./virtual.d.ts`
Content integration	Add authoring formats and content tooling	`packages/integrations/markdoc/tsconfig.build.json` and `packages/integrations/mdx/tsconfig.build.json` reference Markdown-related packages
Monorepo package family	Build, test, and publish official packages together	`package.json` filters scripts over `@astrojs/*`

The comparison with Cloudflare, Netlify, Node, Markdoc, and MDX is useful because it shows what all official integrations share and where UI integrations differ. Adapter build configs include ./virtual.d.ts, and the Cloudflare and Netlify adapters reference ../../underscore-redirects/tsconfig.json, signaling deployment-specific behavior outside the renderer problem. Markdoc and MDX reference ../../markdown/remark/tsconfig.json, while Markdoc also references ../../astro-prism/tsconfig.json and MDX references ../../markdown/satteri/tsconfig.json, signaling content compilation concerns. Sources: packages/integrations/cloudflare/tsconfig.build.json, packages/integrations/netlify/tsconfig.build.json, packages/integrations/node/tsconfig.build.json, packages/integrations/markdoc/tsconfig.build.json, packages/integrations/mdx/tsconfig.build.json

In contrast, the AlpineJS build config in the supplied evidence is minimal: it extends the shared config and references Astro core. That shape matches a renderer-style package whose primary dependency is Astro’s integration contract rather than deployment redirects, server adapter virtual modules, or Markdown processors. The broader UI family listed in the README follows the same official package naming convention, even though their package-specific implementation files are outside this page’s supplied source set. Sources: packages/integrations/alpinejs/tsconfig.build.json, README.md

Installing and Using Framework Integrations

The normal user workflow starts with astro add, the automatic integration setup command described by the official docs. For example, a project can run npx astro add react, pnpm astro add react, or the equivalent command for another package manager. The wizard updates the Astro configuration and installs the needed dependencies. Multiple UI integrations can coexist when a project needs more than one framework, and the docs explicitly allow one or several integrations to be installed and configured in the same Astro project.

After installation, framework components are imported from relative paths in an Astro component script and rendered in the component template. A page can import a JSX, Svelte, Vue, Solid, Preact, or Alpine-backed component from ../components/... and place it next to HTML and Astro components. The default behavior matters: server-rendered static HTML is the baseline, and hydration is opt-in. That model lets teams adopt framework components where interactivity is needed while keeping the rest of a route content-driven and minimal.

A compact setup reference for the official front-end family is:

Package	Role	Typical setup command
`@astrojs/react`	React renderer integration	`npx astro add react`
`@astrojs/preact`	Preact renderer integration	`npx astro add preact`
`@astrojs/solid-js`	SolidJS renderer integration	`npx astro add solid`
`@astrojs/svelte`	Svelte renderer integration	`npx astro add svelte`
`@astrojs/vue`	Vue renderer integration	`npx astro add vue`
`@astrojs/alpinejs`	AlpineJS integration	`npx astro add alpinejs`

Build, Test, and Maintenance Signals

At repository scale, UI framework integrations are maintained as part of the @astrojs/* package family rather than as detached examples. The root package.json build script runs Turbo with filters for astro, create-astro, @astrojs/*, astro-vscode, and benchmark packages. The dev script uses the same family-level filters with high concurrency, and the integration test script targets create-astro and @astrojs/* while excluding language-tools packages. Sources: package.json

Those scripts matter to integration contributors because renderer packages must remain compatible with Astro core and with the monorepo’s TypeScript project-reference graph. The root typecheck command runs tsc -b, so a package like AlpineJS that references ../../astro/tsconfig.json participates in a build order where core types are available before the integration compiles. The root publint script also filters over @astrojs/*, showing that package publishing checks are applied consistently across official integrations. Sources: package.json, packages/integrations/alpinejs/tsconfig.build.json

The root scripts also expose one AlpineJS-specific end-to-end signal: test:e2e runs the Astro e2e suite and the AlpineJS e2e suite, while test:e2e:alpinejs changes into packages/integrations/alpinejs and runs that package’s end-to-end tests. That does not describe every UI renderer’s test strategy, but it confirms that at least one front-end integration has a dedicated browser-level validation path in the monorepo workflow. Sources: package.json

Next Steps

Use this page to choose the right integration category before editing code or project configuration. If the task is to render framework components, start with the front-end integration family and the astro add workflow. If the task is deployment, move to adapter documentation; the Cloudflare, Netlify, and Node build configs show different dependencies and virtual type surfaces. If the task is authoring content formats, MDX and Markdoc are the better reference points because their build configs depend on Markdown packages rather than renderer-only concerns. Sources: packages/integrations/cloudflare/tsconfig.build.json, packages/integrations/netlify/tsconfig.build.json, packages/integrations/node/tsconfig.build.json, packages/integrations/markdoc/tsconfig.build.json, packages/integrations/mdx/tsconfig.build.json

Ask a question...