[@astrojs/svelte] Importing `getContainerRenderer` from `@as

Error message

[@astrojs/svelte] Importing `getContainerRenderer` from `@astrojs/svelte` is deprecated. Import it from `@astrojs/svelte/container-renderer` instead.

What it means

@astrojs/svelte keeps a getContainerRenderer() export on its root entry purely for compatibility: it console.warns and returns the real renderer from ./container-renderer.js (which the integration itself uses via getContainerRendererImpl). The root export is deprecated in favor of the @astrojs/svelte/container-renderer subpath and will be removed in a future release.

Source

Thrown at packages/integrations/svelte/src/index.ts:13

import type { Options } from '@sveltejs/vite-plugin-svelte';
import { svelte, vitePreprocess } from '@sveltejs/vite-plugin-svelte';
import type { AstroIntegration, AstroRenderer } from 'astro';
import { fileURLToPath } from 'node:url';
import type { Plugin } from 'vite';
import { crawlFrameworkPkgs } from 'vitefu';
import { getContainerRenderer as getContainerRendererImpl } from './container-renderer.js';

/**
 * @deprecated Import `getContainerRenderer` from `@astrojs/svelte/container-renderer` instead.
 */
export function getContainerRenderer(): AstroRenderer {
	console.warn(
		'[@astrojs/svelte] Importing `getContainerRenderer` from `@astrojs/svelte` is deprecated. Import it from `@astrojs/svelte/container-renderer` instead.',
	);
	return getContainerRendererImpl();
}

export default function svelteIntegration(options?: Options): AstroIntegration {
	return {
		name: '@astrojs/svelte',
		hooks: {
			'astro:config:setup': async ({ config, updateConfig, addRenderer }) => {
				addRenderer(getContainerRendererImpl());

				// Svelte component libraries from `node_modules` must go through
				// Vite's transform pipeline because Node can't import `.svelte`
				// files. vite-plugin-svelte only marks a package as `noExternal`
				// when it has a `svelte` export condition; a package that merely
				// declares a `svelte` peer dependency is treated as a
				// "semi-framework" package and routed through `optimizeDeps`

View on GitHub (pinned to 52e6c34790)

Solutions

Change the specifier to the subpath: import { getContainerRenderer } from '@astrojs/svelte/container-renderer';
Register the renderer once and reuse the container instance across requests.
Re-run and confirm no deprecation warning prints.

Example fix

// before
import { getContainerRenderer } from '@astrojs/svelte';
Container.addRenderer({ name: 'svelte', serverEntrypoint: await getContainerRenderer() });

// after
import { getContainerRenderer } from '@astrojs/svelte/container-renderer';
Container.addRenderer({ name: 'svelte', serverEntrypoint: await getContainerRenderer() });

Defensive patterns

Strategy: validation

Validate before calling

const src = await readFile('server.ts', 'utf8');
if (src.includes("{ getContainerRenderer } from '@astrojs/svelte'")) {
  throw new Error("Import getContainerRenderer from '@astrojs/svelte/container-renderer'");
}

Prevention

Import container renderers from the /container-renderer subpath only.
Register the renderer once per process rather than per request.
Update custom SSR entries whenever @astrojs/svelte ships a major.

When it happens

Trigger: Manual SSR code imports { getContainerRenderer } from '@astrojs/svelte' (root) to feed experimental_AstroContainer, e.g. container.addRenderer({ name: 'svelte', serverEntrypoint: await getContainerRenderer() }).

Common situations: Upgrading @astrojs/svelte after container APIs were split into a subpath; older custom-server examples; renderers registered per-request so the warning prints repeatedly.

Related errors

AI-assisted analysis of withastro/astro@52e6c34790 (2026-08-18). Data as JSON: /api/errors/d1e160f6ead91305. Report an issue: GitHub.