Respect Starlight frontmatter properties already present in source files

[ChildishhAlbino]

Describe the bug

If a source file has frontmatter properties that would be used by starlight; it would be very useful to respect those in the generated output file.

I.e.
The source file

The generated file

To Reproduce

1. Create a file in an obsidian vault with the title frontmatter property and assign a value different than the title of the page in obsidian
2. Run npm run dev and observe the associated output file.
3. Compare the frontmatter properties.

Expected behavior

The assigned frontmatter; where possible, should be respected.

How often does this bug happen?

Every time

System Info

Windows 11 (WSL Ubuntu)
Node 18.19.1

Additional Context

No response

[HiDeoo]

Thanks for the feedback, super appreciated 🙌

This is a bit of a tricky subject. A user may use a Starlight known frontmatter fields with a different value type or format. An Obsidian plugin could also do the same. Automatically copying known Starlight frontmatter fields by default would require validating all the fields individually, and only copying the ones that are valid and match Starlight expectations. But even then, a user may use a frontmatter field in Obsidian with a value that matches the Starlight expectations but still want that field to be only used in Obsidian and not copied to the Starlight file.

Considering all this, I just released the version 0.4.0 of the plugin with a new copyStarlightFrontmatter option, defaulting to false. When set to true, the plugin will copy all known Starlight frontmatter fields from an Obsidian file to the associated generated page. As the known fields are copied as is, it's up to the user to manually enable this option and ensure that the frontmatter fields in their Obsidian files match the Starlight expectations.

[ChildishhAlbino]

Awesome - I shall try that out. Appreciate it :D