Migrating to `@inox-tools/inline-mod`

[BryceRussell]

Currently, theme configurations have to be JSON serializable, migrating to @inox-tools/inline-mod could allow for more complicated theme configurations that include functions and more. @inox-tools/inline-mod could also greatly improve the internals for creating virtual modules that provide theme assets. This would require a major rework of the current implementation, but it could also provide a large improvement to the experience for theme authors and users.

Things to consider:

• @inox-tools/inline-mod can't guarantee that the code that it generates doesn't have edge cases. How safe is this to use? Are any of the known edge cases not worth the compromise?
• Trying to generate a module from a parsed zod schema will throw errors because the references to the original values are lost. Is there a way around this so that the theme config can be validated and remain parsable for module generation?

[altsalt]

Here's a direct link to the inline-mod package.

This definitely sounds aligned with the goals of ATP. I don't have enough experience with Vite to contribute meaningfully at the moment.

[BryceRussell]

Trying to generate a module from a parsed zod schema will throw errors because the references to the original values are lost. Is there a way around this so that the theme config can be validated and remain parsable for module generation?

I talked to Luiz about this, he mentioned looking into using a factory wrapper. Anything that can't be serialized by inlineMod/defineModule should be inside a factory wrapper