Add Start v1 coverage to Start v2

[birkskyum]

Start v2 is in Release Candidate.

This adds the same coverage to Start v2 as Start v1 has, and adapt if according to the changes in the changelog.

Before

After

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[netlify]

✅ Deploy Preview for solid-docs ready!

Name	Link
🔨 Latest commit	2d8a4d5
🔍 Latest deploy log	https://app.netlify.com/projects/solid-docs/deploys/6a60176803c83400092f1b6c
😎 Deploy Preview	https://deploy-preview-1588--solid-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[jer3m01]

Small SolidBase changes.
Let me know if an extra feature is required, can implement it upstream.

[birkskyum]

Small SolidBase changes. Let me know if an extra feature is required, can implement it upstream.

@jer3m01 I do hit a SolidBase limitation here. I need labels that are project (Start) specific. I'd like to not change Solid core's labels from Latest and v2 (although they could benefit from similar imrpovemnts, but it's out of scope for this PR) - I would just like to have SolidStart show v1 (Latest) and v2 (RC), to make that distinction clear.

The existing routes.version.values metadata is shared by every project. I tried adding separate Start version values with the same paths, but then /solid-start no longer matches because an empty version segment only resolves to the axis default. This broke the SolidStart top-nav link.

So, if SolidBase can land support for project-specific labels, then I'd be able to use the general config instead of the theme config.

[birkskyum]

@jer3m01 , i've removed the versionLabels changes, so this PR is just about the docs content, and then the solidbase changes and the version label update can come in follow-up PRs

[jer3m01]

if SolidBase can land support for project-specific labels

Definitely, will add the label option in overrides:

[birkskyum]

Great! This is my failed attempt so far with the genral config:

• SolidBase Reproduction - Project-specific labels #1589
• Start-specific labels ( v1 and v2 (RC) ) #1590

[LadyBluenotes]

Small SolidBase changes. Let me know if an extra feature is required, can implement it upstream.

@jer3m01 I do hit a SolidBase limitation here. I need labels that are project (Start) specific. I'd like to not change Solid core's labels from Latest and v2 (although they could benefit from similar imrpovemnts, but it's out of scope for this PR) - I would just like to have SolidStart show v1 (Latest) and v2 (RC), to make that distinction clear.

The existing routes.version.values metadata is shared by every project. I tried adding separate Start version values with the same paths, but then /solid-start no longer matches because an empty version segment only resolves to the axis default. This broke the SolidStart top-nav link.

So, if SolidBase can land support for project-specific labels, then I'd be able to use the general config instead of the theme config.

I'm not sure what you mean for this. There are project-specific labels?

Look here for examples of how to do it - https://github.com/kobaltedev/solidbase/blob/main/dev/vite.config.mts

[birkskyum]

We need to override the version option’s label. At the moment, the version selector reads that from the shared routes.version.values metadata, and label is not available in overrides.

My undertanding of the solution @jer3m01 mentioned to solve ( #1590 ), is that it can be used like this:

overrides: [
	{
		project: "start",
		version: "latest",
		label: "v1 (Latest)",
	},
	{
		project: "start",
		version: "v2",
		label: "v2 (RC)",
	},
]