Closed madeleineostoja closed 1 year ago
Is there a reason we have to provide the schema as a file path, rather than just importing it into the config file and passing it directly
Hi @madeleineostoja, can you clarify? In the newest versions of the v1 alpha (which is only compatible with sanity v3), it now only works via finding the sanity.config.ts
file and grabbing the schema from there. In the newest versions, I actually do this so it can pick up on schema items that a plugin may have injected.
If you haven't updated to the latest alpha, there are quite a few breaking changes š . I'd like to express this project and the v1 still very very early but feel free to email me if you'd like to help with the developments.
Iām talking about the sanity-codegen.config.ts
config file you can provide?
Sorry my mistake! I was following the @sanity-codegen/cli
README on NPM, which seems to be from an outdated release compared to the @alpha
release / github.
Now I'm getting some ESM/require compat issues (I'm running it is a module
package / svelte repo), but I'll try debugging that seperately.
Thanks for the amazing tools!
@madeleineostoja did you manage to use the cli to generate the types with your packaged schemas? I'm also having ESM/require issues so I'm really interested if you found a way of making it mork!
Thanks.
I'm trying to use the v1 alpha of sanity-codegen and running into issues with it parsing my schema. Some context ā my schema is in another package (in a monorepo), and the codegen is running where the cms content is consumed. My schema is in typescript and every object/document in it is split out into seperate files and imported into it. It exports a
schema
object that I pass tosanity.config.ts
.However
sanity-codegen
is trying to parse that file and its relationships isn't working. Is there a reason we have to provide the schema as a file path, rather than just importing it into the config file and passing it directly, since the config is js/ts anyway? That seems both a lot cleaner and a lot more foolproof.