inject: implement search-index based search

[myfreeer]

This is not really full-text search, but search over url and title in the search-index.json. The search core should use existing libraries.

• https://github.com/krisk/Fuse
• https://github.com/nextapps-de/flexsearch
• https://github.com/olivernn/lunr.js
• https://github.com/kbrsh/wade
• https://github.com/bevacqua/fuzzysearch
• https://github.com/farzher/fuzzysort

See also #372
Link #179

[myfreeer]

Yari is using fzf.
https://github.com/ajitid/fzf-for-js
https://www.npmjs.com/package/fzf

[myfreeer]

Referring to #785, should make a jsonp-based fallback for file protocol

Or we can just pack the search code and data together in a js, since it should always be static once downloaded.

[myfreeer]

Current repo constraints

• src/mdn/process-search-json.ts already downloads /{locale}/search-index.json and expands its URLs into the crawl graph.
• src/mdn/process-url/drop-resource.ts currently discards /search routes, so the implementation should not depend on mirroring MDN's upstream search page as-is.
• src/mdn/process-html/process-remove-elements.ts removes or hides the live MDN search UI.
• fred/components/site-search/element.js depends on /api/v1/search, which does not exist offline.
• fred/components/search-modal/element.js already contains a small client-side search over search-index.json, including query splitting and ranking.

That last point matters: the repo already has a working lightweight search model to reuse or adapt.

Data reality

From the current downloaded artifacts:

• en-US/search-index.json: about 1.44 MB, 14,265 items
• zh-CN/search-index.json: about 706 KB, 7,472 items

I benchmarked the existing fred-style quickSearch approach against those real files. The simple title filter was about 1.2 ms/query on en-US and 0.54 ms/query on zh-CN in Node 20. That is good enough that a heavier search dependency needs a clear benefit.

Main gaps in the proposal

1. Locale coverage is underspecified

This project is multilingual and also falls back to en-US for untranslated pages. Searching only the locale's own search-index.json will miss many pages that are actually present in the offline output for non-en-US locales.

The proposal should explicitly choose one of these:

• search only the locale index and accept incomplete results
• merge locale index with en-US fallback data, ranking locale hits first
• keep locale-only search, but expose a clear "search en-US results" path

Without that, the feature will look broken in translated builds.

2. Upstream /search must not be mirrored

Recent run analysis showed the live MDN /search route pulls broken mdn.dev assets and HTML shells into asset paths. The offline feature should generate or inject its own static search page and data flow. It should not reuse the remote MDN search route.

3. JSONP fallback is probably unnecessary

For file: protocol, a generated JavaScript data file is simpler than JSONP.

Recommended shape:

• search-index.data.js per locale
• assigns a static array to globalThis.__mdnSearchIndex

That avoids fetch()/CORS problems on file: and keeps the runtime simple.

Library assessment

Based on scope, current build style, and npm package size:

• flexsearch and lunr look oversized for title/URL search
• Fuse.js is capable, but still likely heavier than this use case needs
• wade and fuzzysearch are very small, but probably too bare for ranking/pagination quality
• fuzzysort and fzf are the best fits if fuzzy ranking is required

If the issue insists on a third-party library, prefer fzf or fuzzysort.

If that requirement is optional, the better first step is to extract/adapt the existing fred search-modal matcher and extend it to score:

• exact title
• exact slug tail
• title prefix
• URL/slug term matches
• locale match before fallback en-US

Recommended plan

1. Do not mirror MDN /search; generate an offline-local search page.
2. Load only the current locale's index by default.
3. For non-en-US locales, merge in en-US fallback data or provide an explicit fallback toggle.
4. Package search data as locale-specific JS, not JSONP.
5. Start with the existing lightweight matcher from fred/components/search-modal/element.js.
6. Only add fzf or fuzzysort if ranking quality is clearly insufficient after a prototype.

Bottom line

The proposal is worth doing, but it should be reframed as:

implement an offline-local search page backed by downloaded search-index.json, with explicit multilingual fallback behavior, and avoid a new dependency unless the existing lightweight matcher proves insufficient.