✅ Deploy Preview for rspress-v2 ready!

Name	Link
🔨 Latest commit	8042de2
🔍 Latest deploy log	https://app.netlify.com/sites/rspress-v2/deploys/681c7eda99efea000899f783
😎 Deploy Preview	https://deploy-preview-2079--rspress-v2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

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

✅ Deploy Preview for rspress ready!

Name	Link
🔨 Latest commit	8042de2
🔍 Latest deploy log	https://app.netlify.com/sites/rspress/deploys/681c7edad529f100082a3b12
😎 Deploy Preview	https://deploy-preview-2079--rspress.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 82 (🟢 up 14 from production) Accessibility: 97 (no change from production) Best Practices: 92 (🟢 up 9 from production) SEO: 100 (no change from production) PWA: - View the detailed breakdown and full score reports

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

In this pr, the doc doesn't seem to mention meta-json-schema.json.
Therefore, I was wondering if there are any plans to make meta-json-schema.json publicly available?

I'm hoping to reduce how often I need to leave the IDE, and allow me to use it as follows for in-editor validation and autocompletion:

// .vscode/settings.json
{
  "json.schemas": [
    {
      "fileMatch": ["**/_meta.json"],
      "url": "./node_modules/rspress/xxxPath/meta-json-schema.json"
      // or "meta-json-schema-base.json"
    }
  ],
}

In this pr, the doc doesn't seem to mention meta-json-schema.json. Therefore, I was wondering if there are any plans to make meta-json-schema.json publicly available?

Yeah, of course, it is one of the public features in v2.0,

v2.0 is in prerelease version, and document is not fully covered now

Thank you.

We need to carefully consider whether should we add a new _nav.json.

I personally love splitting _nav.json with the old _meta.json, because in our case, there is only one sidebar, the root _meta.json is used for sidebar but we'd expect it as navbar instead.

I personally love splitting _nav.json with the old _meta.json, because in our case, there is only one sidebar, the root _meta.json is used for sidebar but we'd expect it as navbar instead.

yeah, splitting _nav.json with the old _meta.json brings that this case can be handled easier than before,

but there have already been too many breaking changes here... so I decided to give up this change

but there have already been too many breaking changes here... so I decided to give up this change

That's unfortunate. But what if when there is no _nav.json, we fallback to read _meta.json instead? Would that be considered as breaking change?