mirror of
https://github.com/estruyf/vscode-front-matter.git
synced 2026-11-03 09:02:19 +01:00
Issue: No Astro Content Collections found on new astro project with blog template #558
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/vscode-front-matter#558
Reference in new issue
Block a user
Describe the bug
I expected frontmatter to generate appropriate content types from astro's content collections, but during frontmatter initialization no content collections are found.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Content collections should be found, content types generated and new posts should be created with proper fields in the frontmatter.
Desktop (please complete the following information):
Additional context
I made sure that content types were generated by running
astro syncThanks, @T3sT3ro, for opening this issue. FM retrieves the content collections by executing a script on the Astro project. Normally it should output the error in the VSCode output under the Front Matter CMS category.
Would you be able to check that in order to know what is happening?
Here is the log from that window after removing .frontmatter dir, it's config, restarting vscode and trying to initialize frontmatter anew and selecting astro as framework.
this is the dashboard view after initialization:
I guess step 4 should be populated with detected content types.
Did you install the dependencies in your project?
In the output, I can see Vite cannot be found. I'm guessing this is because of the project is missing the dependencies. The script which retrieves these Astro Collections is using Astro it's project dependencies.
I didn't install vite separately, because I assume it's not needed. Astro works on top of vite and it works out of the box, it prints
vite:somethinglogs, so I assume it's working and is there, somewhere. Inside my node_modules (btw I use pnpm if it's important) I can see:.viteconfiguration directoryviteastrodirectory there is a separatenode_modules/.bin/viteexecutable (bash script) that sets upNODE_PATHwhich adds paths tonode_modules/.pnpm/vite@....pnpmdirectory withvite@4.5.0Based on that I think I have a hunch that it might be something that has to do with pnpm and that the current support in frontmatter makes assumptions about either the node_modules, package manager used or some structure. If I am correct, it may turn out that it also doesn't behave like it should under other package managers.
Maybe a good way to integrate with astro would be using their Integrations API instead?
Indeed, it might be a
pnpmthingy, which I will have to figure out how to fix. The reason why it uses a script to run in the current project, is because it doesn't require front matter to package extra dependencies into the extension.Thank you so much for looking into it and providing all details! This helps a lot.
It has indeed to do with
pnpm.The script imports dependencies as follows:
but for
pnpm, it needs to be updated to:Think we need to include a check to see if
pnpmis used, and when it is, the dependency references need to be updated accordingly.For
zodwe can useimport zod from "astro/zod";instead of the directzodreference. Which would allows us to focus onvitealone.just to remind, that if there are pnpm problems there might also be some problems with yarn (although their packaging model is similar npm so maybe not) and turbo, if someone is using it.
Have you looked into https://docs.astro.build/en/reference/integrations-reference/ and considered maybe creating a lightweight integration in another repo that handles everything to do with astro?
I have seen that integration with Astro indeed, but that would probably require more work 🧐
Got it working on my machine with
pnpm, will push out a new beta version for you to test it out.Fix is included in beta version: 9.4.6818057. Feel free to give it a try.
Verified a project with
yarnand it works fine as it behaves likenpm.Nice, it's detecting content correctly. It doesn't generate appropriate types in some cases though. Below is zod configuration and resulting content types generated:
zod and resulting config type
Result content types:
In words:
optionalfrom zod not respected, all fields arerequired(possibly messed up function definition/arguments order after some refactoring?)default: truetags,categories,heroImage,title, getting assigned improper types (I understand those types may not be always right, but some obvious heuristics could be put in place, some based on zods validation like.string().datetime(), some based on name)publishedandmodifiedare completely missingAside from that I would also think about the UX of the "use template" and "detect content" steps because using "blog template" — which looks like a required step — finalizes the whole configuration and opens the dashboard. I clicked it the first time thinking it would just append some defaults to configs and let me proceed with initialization, but it basically finished everything on it's own. Maybe make it the "step 0" where those buttons are on the very top.
Not sure if above comments belong to this thread or should be moved to separate issues though.
@T3sT3ro, thanks for those insights. Created a new issue with your comments to have a separate thread.
Nice, in that case the original issue seems to be resolved.
So I don't know if it is the same reason, but the issue happened to me on latest Frontmatter and Astro. I however do not get errors in the frontmatter output. Also happens on both npm and pnpm.
My content.config.ts