WeChat Mini Program Radar: an AI-filtered directory for mini program technology choices

What the radar replaces, and who is meant to read it

The problem is not a shortage of WeChat mini program resources. It is that the resources live in long awesome lists where a 2019 component library sits next to a framework that is still receiving commits, and nothing in the list tells you which is which. The README frames the goal as turning WeChat mini program development resources into a radar that can be filtered, assessed and compared, and names three audiences: product, engineering and architecture teams doing technology selection; teams that need to judge the risk in Taro, uni-app, native mini programs, component libraries, cloud development and SDKs; and maintainers who want to convert a historical awesome list into something verifiable.

The dataset is small enough to reason about. The README states the current dataset contains 236 resources, broken down as 6 official documentation entries, 43 tools, 13 plugins, 64 components, 2 backend SDK components and 106 demos. That distribution is worth pausing on. Demos outnumber components, which means a large share of the catalog is examples rather than things you would depend on. The radar's value is in the filtering, not in the count.

This is a selection aid, not a runtime. Nothing in the repository is a mini program framework or a component you install into a mini program. If you came looking for a library, you are in the wrong repository.

How the radar is put together: YAML in, Drizzle and Next.js out

The repository layout shows a Next.js application (app/, components/, next.config.ts, tailwind.config.ts) with a data pipeline beside it. data/ holds the resource catalog, scripts/ holds the TypeScript tooling, drizzle/ holds migrations, and db/ holds the database layer. The scripts reveal the data flow: scripts/import-yaml-to-db.ts loads YAML into the database, scripts/generate.ts produces something from the catalog with a --check mode, scripts/score-resources.ts assigns scores, scripts/enrich-resources.ts enriches entries, and scripts/tracker.ts watches for changes. Each of those has a matching test script, for example test-score-trace.ts and test-tracker.ts, which suggests the scoring and tracking steps are expected to be auditable rather than opaque.

The AI features are not hardcoded to a single vendor. .env.example lists OPENAI_API_KEY, OPENAI_API_URL and OPENAI_MODEL, with a default of openai/gpt-oss-20b:free and a fallback of nvidia/nemotron-nano-9b-v2:free. Those model identifiers look like OpenRouter-style slugs, and the presence of OPENAI_API_URL means the Advisor and Doctor pages can be pointed at any OpenAI-compatible endpoint. That is a real design decision: it keeps the selection logic portable and lets a team keep prompts and answers inside its own infrastructure.

The pages named in the README map onto the workflow. /radar browses by recommendation status, risk level, resource type, category and applicable scenario. /compare puts Taro, uni-app and native mini programs side by side. /advisor takes a 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 project configuration and identifies framework dependencies, outdated approaches and migration risk. /weekly shows the ecosystem report and recent risk signals.

Running wechat-miniapp-radar locally: database, import, first page

The README points at two live deployments, https://miniapp.jjc.fun and https://wechat-miniapp-radar.vercel.app, so the fastest way to evaluate the concept is to open those. Self-hosting is for teams that want their own catalog, their own model endpoint and their own data.

Start by copying the environment template and filling in the values the app expects. The file lists the keys; DATABASE_URL is the one the import and migration scripts need first.

cp .env.example .env

Install dependencies and apply the Drizzle migrations. The package.json script names are db:generate, db:migrate and db:push, so the migration path is explicit rather than automatic.

npm install
npm run db:migrate

Load the YAML catalog into the database, then start the development server. The README gives /radar as the browse entry point, so that is the page to check after the import.

npm run db:import
npm run dev

If the import succeeds, /radar should list resources you can filter by recommendation status, risk level, resource type, category and applicable scenario. The scripts also include db:verify and integrations:verify, which are worth running before you trust the numbers on screen.

For the AI-backed pages you need OPENAI_API_KEY and, if you are not using the default endpoint, OPENAI_API_URL and OPENAI_MODEL. The .env.example defaults are openai/gpt-oss-20b:free with nvidia/nemotron-nano-9b-v2:free as fallback. The repository does not document what happens when both models are unavailable, so treat that as an open question rather than a guarantee.

Where the radar is thin: scoring, freshness and the AI boundary

The scoring step exists as a script, scripts/score-resources.ts, and the repository ships a test for tracing scores, test-score-trace.ts. What the README does not do is explain the scoring formula, the weights, or how a resource's score changes when its upstream project goes quiet. If you adopt this for a real selection decision, the score is a starting filter, not an argument. You still have to open the resource.

The same applies to the AI Advisor. The README says it returns evidence sources, which is the right shape for a selection tool, but the quality of an answer depends entirely on the model you configure and the catalog you imported. A free-tier model slug in .env.example is a sensible default for trying the thing out and a poor default for a decision that affects a production mini program.

The Doctor page takes a pasted project configuration and reports framework dependencies, outdated approaches and migration risk. That is pattern matching over a config file. It cannot see your build output, your bundle size, your cloud function latency, or whether a dependency is actually used at runtime. A clean Doctor result is not evidence that a migration is safe.

Finally, freshness depends on the tracker and the weekly feed, and the repository gives no committed schedule for either. The .env.example includes CRON_SECRET, ADMIN_TOKEN, VERCEL_TOKEN, VERCEL_PROJECT_ID and VERCEL_ORG_ID, which points at a scheduled job running on Vercel, but nothing in the README states how often it runs or what it does when a source disappears.

Taro, uni-app and native mini programs in the Compare view

The most useful thing here is not a competitor comparison but an internal one. /compare places Taro, uni-app and native mini programs next to each other, and the catalog entries describe the difference in approach. Taro is listed as developing mini programs the React way while also generating multi-platform applications. uni-app is listed as a unified framework using Vue syntax for mini programs, H5 and apps. MPX is described as an enhanced mini program framework with deep performance optimization, cross-platform mini program support and full compatibility with native mini program components. WePY is listed as a component-oriented mini program framework. Native mini programs are the baseline those frameworks abstract over.

The practical distinction the radar makes visible is what you give up. A cross-platform framework buys you one codebase and adds a compilation layer between you and the WeChat runtime. Native development keeps you close to the platform and gives up portability. Component libraries such as vant-weapp and tdesign-miniprogram are a separate axis: they change how the UI is written without changing the build. CloudBase Framework sits on yet another axis, deployment rather than authoring.

If you want a direct alternative to this tool rather than a comparison inside it, the honest one is the source material itself: a maintained awesome list plus a spreadsheet. The difference in approach is that an awesome list is prose ordered by hand, while this project stores the catalog as YAML, imports it into a database and exposes it through filterable pages and an export endpoint. That buys you repeatable filtering and a diffable catalog. It costs you a Postgres instance, a Next.js deployment and an import pipeline to keep alive.

Licence and the ongoing cost of keeping the radar honest

The repository is licensed GPL-3.0. For a tool you run internally, that is usually unremarkable. If you fork it and expose the modified version to users over a network, the GPL's source-availability expectations are the thing to read, and that is a question for your own legal review rather than something this article can settle.

Maintenance cost is the part teams underestimate. The last push to the repository was on 2026-08-07, so the code is recent, but the catalog inside it is a different artifact with a different clock. Every entry you add is a commitment to re-check it. The repository gives you the machinery for that: scripts/tracker.ts to detect changes, scripts/enrich-resources.ts to refresh metadata, scripts/generate.ts --check to catch drift, and a weekly page to surface risk signals. It does not give you the people to run them.

There is also a hosting surface. The .env.example references DATABASE_URL, Blob storage via BLOB_READ_WRITE_TOKEN, and two interchangeable key-value options, UPSTASH_REDIS_REST_URL with UPSTASH_REDIS_REST_TOKEN and KV_REST_API_URL with KV_REST_API_TOKEN. That is a real deployment footprint, not a single binary. OPERATION_LOG_RETENTION_DAYS defaults to 30, which tells you the operation log is expected to grow and needs trimming.

Editorial conclusion

Adopt it if your team is choosing between Taro, uni-app and native mini programs and you want the criteria written down as data you can filter and export, and if you are willing to point it at your own database and OpenAI-compatible endpoint. Do not adopt it if you need a maintained hosted product, a library you import, or an answer you can trust without reading the cited evidence. Before committing, run npm run db:migrate and npm run db:import against a throwaway Postgres instance, then open /doctor with one real project config to see whether the dependency detection flags anything you did not already know about.

Frequently asked questions

Official sources

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