Changes

• In picocolors is being bundled into the browser #14692 (comment) a user pointed out that they expected Astro to automatically “know” not to include .astro components in client code, allowing a mixed barrel file that exported both Astro and JSX components (this works in build currently but not dev since Replace kleur with picocolors #14598). (I’m not sure if that should be supported, but people are doing it, and on the surface these imports are used in the same place in the same way, so I was curious if we could allow it for now.)
• This PR stubs out the compiled Astro component when imported in non-SSR contexts. In dev, it exports a default function (similar to compiled .astro) that throws an error if used. In prod, it just exports an empty object.
• This also has the advantage of skipping some pointless compiler calls in dev mode if people are doing this.

Testing

I added a test for dev and build behaviour.

I also tested manually by creating a barrel file in the framework-react example to re-export a React component and a simple Astro component:

export { default as Counter } from './Counter';
export { default as Example } from './Example.astro';

I also excluded picocolors from optimized deps in the example config because Vite automatically optimizes this in the monorepo, but not in user projects:

	vite: {
		optimizeDeps: {
			exclude: ['picocolors'],
		},
	},

I then imported both components from that barrel file and rendered them. Using client:load on the React component.

Before changing astro, the example project fails to hydrate due to trying to load picocolors (i.e. server code). With the change from this PR in place, everything works as expected in the example, with no hydration issues caused by server code being present during dev.

Docs

n/a — bug fix. Although maybe we should consider removing the example in the “Publish to NPM” guide that explicitly shows the mixed Astro/React barrel file code if we’re unsure that’s a best practice.