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

[Yuhanawa]

Hello, I trid to implemented it, but it made a break change in index.ts
it's like:

export const configSchema = z.object({
	title: z.string(),
...
});

export default defineTheme({
	name: "theme-playground",
	schema: configSchema,
...

then, i trid to aviod,
I found meybe we don't need @inox-tools/inline-mod, globalThis can achieve the same effect

(globalThis as any)[themeName].config = userConfig;

const virtualImports: Parameters<typeof createVirtualResolver>[0]["imports"] = {
    [`${themeName}:config`]: `export default globalThis["${themeName}"].config;`,
    ...
};

Are there any negative consequences of using globalThis?

[BryceRussell]

This is awesome! I am not sure if there are any negatives to using this pattern. This is definitely something we should explore!

[BryceRussell]

I talked to Fryuni about this more. Storing the config inside a global will make this break for SSR environments, so we have to use inline-mod or possibly another magical solution, we will have to explore more to figure out what works best.