mybatis-plus-doc: the Astro and Starlight source behind the MyBatis-Plus handbook
MyBatis-Plus Official Documentation
At a glance
- What is it?
- The MyBatis-Plus documentation is not a folder of Markdown but a small Astro site with Starlight, Svelte and Tailwind, plus a translation plugin that pipes Chinese source pages through an LLM to produce English and Japanese versions. It is worth reading if you want to know how the framework's own guidance is maintained, and it is worth forking if you want the same setup for your own docs.
- Who is it for?
- Adopt this repository as a reference if you are extending MyBatis-Plus and want the exact wording of the official pages, or as a template if you want a documentation site that ships its own machine-assisted translation pipeline. Skip it if you only need the framework itself, since the runtime library lives in a separate mybatis-plus repository and the site carries no Java code.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 67 days ago.
- What is it written in?
- Mainly MDX, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A documentation site built as an application, not a folder of Markdown
Most documentation repositories are a directory of .md files with a static site generator pointed at them. This one is different in shape. The top level holds astro.config.mjs, doc.config.mjs, svelte.config.js, tailwind.config.mjs and tsconfig.json alongside src/, public/, package.json and a translation-plugin/ directory, and the primary language is recorded as MDX. The package identity makes the intent clear: the package is named mybatis-plus-doc-new, marked private, declared as an ES module, and carries the placeholder version 0.0.1. That version number is a tell. Nothing here is published as a package, because the deliverable is a website, and the site serves the handbook at baomidou.com while the framework source and issue tracker live in the separate mybatis-plus repository. There is also a Gitee mirror listed for code hosting. If you are looking for a MyBatis-Plus runtime dependency to drop into a build, this repository is the wrong place. It is the place to read, translate or fork the guidance itself.
Starlight for docs structure, Svelte and Tailwind for the shell
The dependency list shows how the site is assembled. @astrojs/starlight at ^0.21.4 handles the documentation layer, which is what produces the sidebar, table of contents and search experience typical of a framework handbook. @astrojs/sitemap at a pinned 3.6.0 generates the sitemap, and @astrojs/check at ^0.5.10 runs type checking as part of the build script. @astrojs/svelte at ^5.3.0 with svelte at ^4.2.12 brings interactive islands into an otherwise static site, while tailwindcss at ^3.4.3 and @astrojs/tailwind at ^5.1.0 handle styling. Two of those pairs deserve a second look before you copy them. The @astrojs/svelte adapter is on a 5.x line while the svelte runtime itself is on 4.2, and @astrojs/tailwind sits on 5.x while tailwindcss sits on 3.x. Those version families are not the same generation, and anyone adopting this stack should confirm the pairing works for their own setup rather than assuming it. Two more details sit alongside them: sharp at ^0.33.3 for image processing and store2 at ^2.14.3 for client side state.
Running the site locally with astro dev
The scripts section defines the whole local workflow, and it is short enough to read in one pass.
"dev": "astro dev",
"build": "astro check && astro build",
"preview": "astro preview",There is no separate serve script because dev and start both point at astro dev. The build is where type checking happens, since astro check runs before astro build rather than as a separate CI step, which means a broken type in a page or component fails the build instead of shipping. The preview command serves the built output the way a static host would. You should expect a local Astro dev server on its default port with the Starlight layout, a sidebar built from the configuration in doc.config.mjs, and MDX pages rendered from src/. If the site starts but a route 404s, the fault is most likely in how doc.config.mjs describes that route rather than in the build, since the build itself would have failed first.
The translation plugin sends Markdown through an LLM
The interesting part of this repository is translation-plugin/, driven by node scripts that live in package.json.
"translate": "node translation-plugin/translate.js",
"translate:en": "node translation-plugin/translate.js --lang en",
"translate:ja": "node translation-plugin/translate.js --lang ja",
"translate:check": "node translation-plugin/translate.js --dry-run",Each language gets its own script and there is a dry-run mode for checking without writing. The devDependencies tell you how it works under the hood: @themaximalist/llm.js is the model client, commander handles the command line flags, glob finds the source pages, gray-matter reads the front matter, inquirer and listr2 drive interactive prompts and task lists, and ora, cli-progress, cli-table3, boxen and chalk render progress and summary output. So the pipeline is: collect .md and .mdx files, parse their front matter, send the body to a model through the client, then write the result out per language. That mechanism has a consequence worth stating plainly. A machine translation of a technical page is a draft, and the upstream project treats it as such, which is why the README asks contributors to help with translation and revision of the documentation rather than shipping generated text unattended.
Where translated output goes, and the keys that control it
The .env.example file is a complete configuration reference for that plugin, and it is short.
AI_PROVIDER=deepseek
API_KEY=your_deepseek_api_key_here
TRANSLATION_CACHE_DIR=translation-plugin/cache
TRANSLATION_MAX_CONCURRENCY=3
TRANSLATION_RETRY_COUNT=3
DEBUG=false
VERBOSE=falseThe comments in the file are instructions rather than decoration: copy it to .env, fill in your API key, adjust the other settings as needed, and make sure .env has been added to .gitignore. Three of these values change the behaviour of a run in ways you will feel. TRANSLATION_MAX_CONCURRENCY caps how many pages are translated at once, TRANSLATION_RETRY_COUNT sets how often a failed call is retried, and TRANSLATION_CACHE_DIR decides where already translated pages are remembered so a rerun does not re-bill the model for work it has already done. The API key is required, and DEBUG and VERBOSE control how much the tool prints while it runs. The default provider is deepseek, which means the example configuration expects a model service account of your own, not a shared one.
The ecosystem the handbook documents, and who maintains it
The README positions this site inside a wider family of projects rather than presenting the handbook as a standalone artefact. Listed alongside it are MybatisX, described as a free IDEA plugin with jump navigation, SQL auto-completion and code generation; MyBatis-Mate, which provides enterprise modules such as sharding, data auditing, field encryption, data permissions and automatic SQL maintenance from table structure; Dynamic-Datasource, a SpringBoot multi-datasource component; Shuan and Kisso for web security and cookie based single sign-on; Lock4j for distributed locks over RedisTemplate, Redisson and Zookeeper; Kaptcha for simple captchas; and the FlowLong and SnailJob workflow and scheduling platforms. This matters for adoption because it explains the audience: the documentation is written for Spring Boot teams operating at enterprise scale, not for a hobby project with one table. The README also notes that MyBatis-Plus received the OSC award for most popular Chinese open source software five years in a row from 2017 through 2021, and it points to a separate awesome-mybatis-plus repository for tutorials, case studies and a list of users. Contribution happens in two places: code goes to the mybatis-plus repository, documentation, translation and revision to this one.
A repository with no releases and a dated last push
The maintenance facts here are modest, and it is better to state them than to dress them up. There are no GitHub releases for this repository, which is consistent with it being a documentation site rather than a distributed artifact, and the last push was on 2026-08-17. The repository root also holds a CLAUDE.md file and a .github/ directory, so there is contributor onboarding material alongside the site configuration. One point deserves attention from anyone planning to reuse the code: the repository does not state a license for the documentation itself. The framework in mybatis-plus is licensed separately, and the ecosystem repositories carry their own terms. If you plan to copy the translation plugin or the site configuration into your own project, resolve the licensing question first, since a missing license on the documentation repository leaves reuse on shaky ground.
Editorial conclusion
Adopt this repository as a reference if you are extending MyBatis-Plus and want the exact wording of the official pages, or as a template if you want a documentation site that ships its own machine-assisted translation pipeline. Skip it if you only need the framework itself, since the runtime library lives in a separate mybatis-plus repository and the site carries no Java code. Before using the translation plugin, verify that AI_PROVIDER and API_KEY in .env point at a provider you are willing to bill and that TRANSLATION_CACHE_DIR is writable, because every translated page passes through an external model.
Frequently asked questions
What is mybatis-plus-doc and what does it contain?
It is the official documentation source for MyBatis-Plus, described in the README as the online documentation library. The content lives in src/, the site is configured through astro.config.mjs and doc.config.mjs, and the published handbook is hosted at baomidou.com.
How do I run the MyBatis-Plus documentation site locally?
Install the dependencies from package.json and run the dev script, which invokes astro dev, then use the preview script to serve the built output. The build script runs astro check before astro build, so type errors fail the build rather than shipping.
How does the translation plugin generate the English and Japanese versions?
The plugin in translation-plugin/ is driven by node scripts and uses @themaximalist/llm.js as its model client, glob to find source files and gray-matter to parse front matter. It reads AI_PROVIDER, API_KEY, TRANSLATION_CACHE_DIR, TRANSLATION_MAX_CONCURRENCY and TRANSLATION_RETRY_COUNT from a .env file you create by copying .env.example.
Does translating the documentation cost money or need an API key?
Yes. The .env.example comments instruct you to copy the file to .env and fill in your API key, with AI_PROVIDER defaulting to deepseek. The cache directory keeps already translated pages so reruns avoid repeating paid calls.
Where do I file bugs about MyBatis-Plus itself rather than its docs?
Code issues and pull requests go to the mybatis-plus repository, while documentation changes, translations and revisions go to mybatis-plus-doc. The README lists both GitHub and Gitee for code hosting and baomidou.com for the online documentation.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/baomidou-mybatis-plus-doc)Was this useful?