feat: Add custom JSON-LD structured data support for blog posts

[LindsayLiu777]

Summary

Allow blog posts to export custom JSON-LD structured data (FAQ, HowTo, etc.) for Google rich snippet eligibility.

Changes

• Modified blog/[slug]/page.tsx to read optional jsonLd export from MDX files
• Renders additional JSON-LD script tags when present
• Added TypeScript type declaration in mdx.d.ts
• Backward compatible: posts without jsonLd export work unchanged

Usage

In any MDX blog post:

export const jsonLd = [{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [...]
}];

Test plan

• TypeScript typecheck passes (all 5 packages)
• All 803 tests pass
• Verify blog posts without jsonLd export still render correctly
• Verify blog posts with jsonLd export render the additional script tags

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[gusye1234]

Code Review — PR #338 (custom JSON-LD support)

Reviewed the diff. Clean, well-scoped change. CI green, tests pass, backward compatible.

Looks good:

• Optional jsonLd export is destructured off the dynamic MDX import — posts without it are unaffected.
• Array-wrapping (Array.isArray(jsonLd) ? jsonLd : [jsonLd]) is the right normalization — Google accepts a JSON-LD array in a single <script> tag.
• Type declaration in mdx.d.ts matches the runtime shape.
• Sits alongside the existing blogPostingJsonLd script without conflict.

Minor nits (non-blocking):

1. Empty-array/object rendering. {jsonLd && (...)} will still render a <script> tag if a post exports jsonLd = [] or jsonLd = {}. Consider {jsonLd && (Array.isArray(jsonLd) ? jsonLd.length > 0 : true) && (...)} if you want to guard against empty exports. Very minor — probably not worth the extra logic.
2. Type nit. export const jsonLd: ... | undefined — since this is a const, TS-wise it's always defined at value-time; the undefined union is more about "the module may not export this at all." Works fine as-is, just noting that ? on a namespace/module member is a slightly more idiomatic way to express "optional export" (but TS doesn't support that on *.mdx module declarations, so this is fine).
3. Validation. No runtime validation that the exported object is well-formed JSON-LD. Since these are authored MDX files (not user input) and injected via dangerouslySetInnerHTML, malformed JSON-LD is a authoring issue, not a security issue — JSON.stringify handles the escaping. Fine to leave as-is.

Assessment: Ready to merge from a code perspective. No blockers.