Error hydrating: picocolors does not provide an export named 'default'

[rktyt]

Astro Info

Astro                    v5.15.1
Vite                     v6.4.1
Node                     v20.19.1
System                   Linux (x64)
Package Manager          npm
Output                   server
Adapter                  @astrojs/node (v9.5.0)
Integrations             @astrojs/react (v4.4.0)

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

After updating from 5.14.8 to 5.15.1, an error started appearing in the browser console.

[astro-island] Error hydrating /src/components/Header.tsx SyntaxError: The requested module '/node_modules/picocolors/picocolors.browser.js?v=70bfba13' does not provide an export named 'default' (at endpoint.js?v=70bfba13:1:8)

I’m checking it with npm run dev.

Updates

Essentially, is this the same issue as #14577 ?

It seems to occur even when using images other than SVG, such as PNG, in a client component.

What's the expected result?

No errors

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-v3vslw94?file=astro.config.mjs

Participation

• I am willing to submit a pull request for this issue.

[florian-lefebvre]

cc @delucis probably a regression from #14598

[delucis]

Oh, weird, why is that being used in the browser?! (Picocolors does support browser environments, but super weird that it's used at all.)

Just catching a train but can take a look in a bit. May be worth a revert in the meantime to be safe if someone has a minute?

[delucis]

Looks like picocolors isn't ESM-only and the Common JS module.exports usage in their browser bundle is breaking stuff. There are a couple of issues in the repo that haven't been responded to, e.g. alexeyraspopov/picocolors#70

Sorry for not testing this more thoroughly, I'd expected issues like this to be picked up by our build and test suites.

We should

1. Revert for now
2. Try to figure why this is pulled in at all. It presumably means folks are currently bundling kleur for this usage which is not good 😄

[delucis]

Just leaving a note to say I do think this is basically related to #14577 — the SVG import pulls in the entire server runtime, which in this case happens to include terminal text styles, and therefore picocolors. I’m guessing at build time it’s often OK because stuff gets tree-shaken out. Still, I wonder if we can try to isolate the assets from the server runtime a bit to make this less fragile.

[ematipico]

I don't think we should revert the change, and I think we should fix the issue you linked.

As you said, technically we're doing something wrong when bundling stuff, and that's not the logging library :)

[delucis]

Seems tricky to solve 100% even if we can mitigate things a bit.

I started by looking at the assets plugin thinking “If the SVG is imported in a client component, we can avoid attaching the Astro component instance”. But I don’t think it quite works like that: in Vite/Rollup we can try to work out what kind of file is doing the importing and decide how to resolve that, but we can’t do that on per-usage basis. Once a module is loaded, it is loaded for all usages. So we could detect that an SVG has a dependent that is JSX/TSX/Svelte/Vue, but if the SVG is used in both Astro and one of those, we’d need to include the Astro component instance for both.

So mitigations we could consider:

1. (easy) — reduce what src/assets/runtime.ts imports by not importing from the runtime/server/index.js barrel file
2. (more work) — audit and refactor those direct imports to reduce this further
3. (not sure if feasible or worth it) — implement logic in src/assets/vite-plugin-assets.ts to only attach the component if we detect usage in .astro

Finally, I guess in theory a refactor of the SVG component feature might be possible to avoid this? But I’m not 100% sure of the ideal design. In theory Astro’s renderer could contain the logic for rendering an SVG ImageMetadata object instead of attaching an Astro component to the metadata object.

[delucis]

I take the above back, the fix may in fact be simple? See #14623.

Want to do a bit more testing, but appears to work.

[JoostKersjes]

Not sure this is useful feedback, but I'm still seeing this Error hydrating: picocolors does not provide an export named 'default' error on our fully static website project after locally upgrading to astro@5.15.2.

[delucis]

Hi @JoostKersjes! Could you share a reproduction where this happens? At least for the reproduction shared in this issue, the error no longer occurs with 5.15.2, so we’d need some project where we can see the error still happening to figure out why.