fix for astro 6.

[enigmalea]

• Confirmed support on Astro 6.x
• Confirmed support on Astro 5.x
• Confirmed support on Astro 4.x

[enigmalea]

@essential-randomness Whew. Okay. So this is a PITA.

• For the plugin to work with Astro 6.x your content collection must have been updated to use a loader. If you don't do this, the plugin doesn't properly work with vite/astro; it doesn't loop through the array of social links properly and fails to identify the links - it stops with the first link and assigns it the default case. (you will not believe how long it took me to diagnose this.)

• I have attempted everything possible to support both zod 3 and zod 4 in the same release and it doesn't appear possible without a breaking change. the most recent commit attempts to detect the version of zod from the environment and choose the correct zod schema. It works in Astro 6.x beautifully. Somehow, even without me updating anything, I ended up with Zod 4 in my Astro 5 project, and the incorrect version is being detected and used by the plugin, so Astro 5 fails to run. Because of the chaos of the Node environment that means it's not a stable option for legacy support to detect the correct zod version from the environment.

  • One solution might be to remove zod distribution from the plugin and to write a function that uses the users z instance to create a socialSchema Problem: This would remove SocialSchema and SocialLinks as ready made imports, which would be a breaking change for existing users because their imports would need to be updated to import the function instead.

    Example:

    import { z } from "zod"'
    import { createSocialSchema } from "@fujocoded/zod-social-schema";
    
    const SocialLinks = createSocialSchema(z);

  • The other option (cleaner for users, but messier for maintenance) is to have two separate release branches. We could create @fujocoded/zod-transform-socials@legacy to support zod 3/Astro 5 and earlier. People who aren't ready to upgrade to Astro 6 can stay on that branch.

What would your preference be?

Either way this still needs work because the code can be simplified back down from my attempts to support both versions in one codebase. 😊