wechat-miniapp-radar: an AI-assisted selection index for the WeChat Mini Program ecosystem

The selection problem it targets, and the teams it assumes

WeChat Mini Program work accumulates a specific kind of debt: a framework choice made in 2019, a component library that stopped shipping, a cloud function SDK that no longer matches the current base library. The README frames the audience narrowly. It names product, engineering and architecture teams doing technology selection, teams that need to judge the risk of Taro, uni-app, native mini programs, component libraries, cloud development and SDKs, and maintainers who want to convert historical awesome lists into something filterable and comparable. That last group is the most concrete. An awesome list is a flat document. Radar is the same material with status, risk level, resource type, category and applicable scenario attached to each entry, which is the difference between a reading list and a shortlist. The project is not a framework and not a build tool. It is an index with a query interface on top, and the value it offers scales with how current that index is.

The data set: 236 resources, unevenly distributed

The README reports 236 resources in the current data set, broken down as 6 official documents, 43 tools, 13 plugins, 64 components, 2 backend SDK components and 106 demos. That distribution is worth reading before you trust the category filters. Demos are the largest single group at 106, which means roughly 45 percent of the index is sample projects rather than things you would put in a production dependency tree. Components at 64 and tools at 43 are the parts a selection process actually consumes. Backend SDK components number 2, so any question about server-side integration will hit the edge of the data set quickly. The sample entries listed in the README span Taro, uni-app, MPX, WePY, vant-weapp, tdesign-miniprogram and CloudBase Framework, with the star figures the README itself prints. Those figures are the project's own labels and change over time; the index does not appear to be a live mirror of repository metadata. Treat the counts as a snapshot of what has been catalogued, not as a measure of ecosystem size.

Five surfaces: Radar, Compare, Advisor, Doctor, Weekly

The routes are explicit in the README: `/radar`, `/compare`, `/advisor`, `/doctor` and `/weekly`. Radar is the browsing and filtering layer, with facets for recommendation status, risk level, resource type, category and applicable scenario. Quick Search sits alongside it for jumping to known pages. Compare is scoped to the core frameworks, described as Taro, uni-app and native mini programs, so it is a small fixed comparison rather than an arbitrary diff between any two index entries. Advisor takes a free-text selection question and returns a recommendation, conditions where it applies and does not apply, migration cost, next steps and evidence sources. Doctor takes a pasted mini program project configuration and identifies framework dependencies, outdated approaches and migration risk. Weekly publishes ecosystem reports and recent risk signals. The split matters: Radar and Compare are deterministic views over the data set, while Advisor and Doctor produce generated text, and the README's own description of Advisor returning evidence sources is the mechanism that keeps the generated part checkable.

How the Doctor input actually works, and where it stops

Doctor is the feature most likely to be misunderstood. It accepts a pasted project configuration, not a repository URL and not a directory path. That constrains what it can see: dependency declarations and configuration keys, not source files, not build output, not runtime behaviour. A project that has already partially migrated, or one whose framework dependency is injected by a build script, may present a configuration that does not reflect what actually runs. The README states that Doctor identifies framework dependencies, outdated approaches and migration risk, which is a reasonable claim for configuration-level analysis and an overreach for anything requiring code inspection. There is no mention of a CLI, an npm package, a GitHub Action or a pre-commit hook, so this is a browser workflow. If your review process requires the check to run in CI, this is the wrong tool for that step, and the gap is architectural rather than a missing flag.

Running it: the deployment path the README actually shows

The README does not include an install section. What it provides is a hosted instance at `https://miniapp.jjc.fun` and a Vercel deployment at `https://wechat-miniapp-radar.vercel.app`. The Vercel URL is the only deployment detail in the README, and it implies a serverless hosting model for the Next.js-style route structure (`/radar`, `/compare`, `/advisor`, `/doctor`, `/weekly`). There is no documented environment variable, no API key name, no database connection string and no self-hosting walkthrough in the supplied text. That is a real gap for anyone who wants to run the Advisor or Doctor against a private data set, because generated answers normally require a model credential, and the README never names one. If you need a self-hosted instance, plan to read the repository itself for the configuration surface, because the README will not get you there. The primary language is TypeScript, so the codebase is readable to most front-end teams once they are in it.

Licence and the cost of keeping a radar current

The licence is GPL-3.0. For a hosted site this is unremarkable. For a team that wants to embed the Advisor or Doctor logic inside a closed-source internal portal, the copyleft terms are the first thing to check with whoever handles licensing at your organisation, since GPL-3.0 carries obligations that a permissive licence does not. On maintenance, the repository supports one observation and no more: the last push is 2026-08-07, there are no retrieved releases, and the data set is described as containing 236 resources at the time of writing. A radar whose usefulness depends on freshness has an ongoing cost that a static library does not, because every entry needs re-checking as frameworks ship or stall. The README does not describe a contribution process, a data schema, a scheduled refresh job or an update cadence. Without those, the practical question for an adopter is who re-verifies the entries and how often, and that answer is not in the documentation.

The alternative it is not: a lockfile scanner

The closest functional alternative is a dependency and advisory scanner such as `npm audit`, Dependabot or Renovate, and the difference in approach is worth stating plainly. Those tools read a lockfile, resolve the dependency graph, and match versions against advisory databases. They answer whether a specific installed version has a known problem, and they answer it automatically on every push. Radar answers a different question: which framework or component library a team should pick in the first place, and what the migration cost looks like if they picked wrong. It works from a curated catalogue with human-assigned risk levels and applicable scenarios rather than from version ranges and CVE identifiers. Neither replaces the other. A team that already knows its stack still needs the lockfile scanner. A team at the start of a mini program project, or one maintaining a list of candidate libraries, has no lockfile to scan yet, and that is the gap Radar fills.

Who should adopt it, and what to verify before trusting a recommendation

Use it when you are at the front of a decision: comparing Taro against uni-app against native mini programs, building a shortlist of component libraries, or auditing a pasted configuration for outdated framework dependencies. The Advisor's habit of returning evidence sources alongside its recommendation is the part that makes the output usable in a review meeting, provided you actually follow those sources. Skip it if you need runtime tooling, an automated migration script, or a CI-integrated check, because none of those are described. Also skip it if your stack is server-heavy, since the index holds 2 backend SDK components. Three things to verify first. Check the source link on any resource card you plan to depend on, because the index records a resource, not its current health. Confirm whether the Advisor and Doctor require a model credential you would have to supply and pay for, since the README names none. And confirm the data set has been refreshed after 2026-08-07, because a radar that has not moved is a snapshot of an older ecosystem.

Editorial conclusion

Adopt it as a reading surface when you are choosing between Taro, uni-app, native mini programs and their component libraries, and treat the Advisor and Doctor outputs as prompts for your own review rather than verdicts. Do not adopt it if you need a runtime library, an automated codemod, or a tool that can inspect a real repository instead of a pasted config. Before relying on any recommendation, open the source link on the resource card, check the last push date of that repository yourself, and confirm the data set has been refreshed since 2026-08-07.

Official sources

1. Issues
2. justjavac/wechat-miniapp-radar on GitHub
3. License: GPL-3.0
4. Project website
5. README