Search Implementation

[LordSimal]

Important

EVERYONE is welcome to include their opinion about this topic!

Vitepress currently uses minisearch as a JS, browser based searche engine. This means we don't need to maintain a elastic search or other search index specific serivce (internally or externaly)

But one thing to keep in mind related to the search is the fact, that the current search index being generated while building is using only the 5.x version, not the older versions.
https://github.com/cakephp/docs/blob/5.x-vitepress/.vitepress/config.js#L27-L37

Not sure if the search can be version dependent. There is of course the possibility to connect to an algolia search index but I wouldn't go there in the current state.

[markstory]

This means we don't need to maintain a elastic search or other search index specific serivce (internally or externaly)

Yay 👏

But one thing to keep in mind related to the search is the fact, that the current search index being generated while building is using only the 5.x version, not the older versions.

Is having multiple versions impossible? We'll need to have search for each version separate from the other versions.

[LordSimal]

Is having multiple versions impossible? We'll need to have search for each version separate from the other versions.

yes, but only if we make separate builds for each version.

[markstory]

yes, but only if we make separate builds for each version.

I think that's ok. That's how we do builds today.

[josbeir]

"I'm not sure about this. Building a VitePress site for each version would lose uniformity and the ability to smootly switch between versions and pages easily like the Vue integration now provides.

We'd then also need to figure out how to handle pages that aren't part of the main 'book.' For instance, if you're on the 4.x site and go to the book index, you'd have to switch back to the 5.x page, which breaks the version context.

I think a better idea is to create a separate repo for the VitePress site. A workflow or Dokku job could then fetch the branches from the docs repo during the build. This would stage everything to build and deploy one single VitePress site.

This way, we would have seamless toggling between versions and pages, just like we do now. It would also be much easier to push changes to all versions since it's just one site.

I think it is possible to adjust the stock search component and indexer to build minisearch indexes for each version and toggle between them based on the current version. I'll look into that. 👁️

update: there is of course something to say about seperate envs too as it would solve the search issue and much faster build times.

@markstory what about the algolia search as @LordSimal proposed? Many open source projects use their services these days, could be something to look into or reach out to them ?

[markstory]

Algolia could be an option but our budget for additional hosted services is $0/month 😢

[ADmad]

Algolia could be an option but our budget for additional hosted services is $0/month 😢

Algolia has a open-source tier https://www.algolia.com/for-open-source

Or there are other self hosted alternatives like typesense, millisearch etc. which are supposedly easier to manage than elastic search.