Allow custom paths for content

[fea17e86]

What version of starlight are you using?

0.15.0

What is your idea?

Hi!

I would like other directories to be allowed as the root for starlight content. For example, instead of having the docs located in src, like:

src/
   content/
      docs/

I would like to have them in the root of my repository, like:

docs/
src/

The configuration should allow me to configure directories outside of the source directory to be scanned for content. This should also allow to separate the content from components.

Why is this feature necessary?

I love Markdown (and I believe it is the reason why it is so popular) for being (mostly) very well readable in the raw text form and obviously in the rendered HTML form. This is why I want to use it for my tech documentation.

It is just extremely helpful to be able to immediately find and read the documentation of a project, without being hidden in a src directory and somewhat mixed with components and such.

This would somewhat follow the philosophy behind progressive enhancement, in the way that you have access to a tidy, minimal, always readable documentation (Markdown) and only if you access the deployed starlight pages you access the improved UI and UX.

Do you have examples of this feature in other projects?

No response

Participation

• I am willing to submit a pull request for this feature.

[mere]

+1 to @fea17e86's idea. I would like to use starlight in a monorepo, where it collates the docs from multiple packages.
Being able to change src/content/docs/ to a custom array of entry points (ideally using filter patterns) would be very useful.

[jorenbroekema]

Yeah I would also very much appreciate if I could put all my contents inside a docs folder into the root of my project, my project is a JS library and its source files already live in the src folder, I'd love it if I could keep docs and library source files in separate folders

[mere]

As a workaround, I symlinked the docs folder into the root, it worked well.

[delucis]

Just to link it here, this will hopefully be more easily solved by current work on Astro’s content collections system. For people who want to follow along with that work, there’s a roadmap discussion: withastro/roadmap#946