Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating to @inox-tools/inline-mod #32

Open
BryceRussell opened this issue Mar 31, 2024 · 4 comments
Open

Migrating to @inox-tools/inline-mod #32

BryceRussell opened this issue Mar 31, 2024 · 4 comments
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested

Comments

@BryceRussell
Copy link
Member

BryceRussell commented Mar 31, 2024

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?
@BryceRussell BryceRussell added enhancement New feature or request help wanted Extra attention is needed question Further information is requested labels Mar 31, 2024
@altsalt
Copy link
Contributor

altsalt commented May 3, 2024

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
Copy link
Member Author

BryceRussell commented May 5, 2024

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
Copy link
Contributor

Yuhanawa commented Dec 6, 2024

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?

Image

@BryceRussell
Copy link
Member Author

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

Yuhanawa added a commit to Yuhanawa/astro-theme-provider that referenced this issue Dec 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants