Douyin-Vue: a Vue3 feed that answers itself from local JSON

axios-mock-adapter fakes the backend, so there is nothing to point at a server

The absence of a backend is the design, not a gap. Data is kept inside the project, and axios-mock-adapter intercepts API calls and returns local JSON to imitate a real backend request. The dependencies line up with that story: axios ^1.15.0 for the requests, axios-mock-adapter ^1.22.0 for the interception layer, and mockjs ^1.1.0 sitting alongside for fabricating responses. What the arrangement cannot do is talk to anything live. The consequence for a reader is that every piece of content you see is content someone committed to the repository, and the only way to add or change a feed is to edit the local JSON and reload. That is fine for studying the interface and useless as an integration test.

A zip download will not run, and the only way in is a git clone

The install instructions are unusually firm about this: the project must be cloned with git, and downloading the zip package will not run. No reason is given, so anyone hitting a failure after unpacking an archive has nothing to debug from. The documented path is:

git clone https://github.com/zyronon/douyin.git
cd douyin
npm install
npm run dev

The gitee address is offered for users in China, and the README also points at a one-click Vercel clone for people who would rather not clone at all. The consequence is that your first five minutes are spent on tooling rather than on the code, and that anyone following the README from a downloaded archive will report a bug that is really a broken setup step. Note that the dev, start, and serve scripts are all `vite --host`, so the dev server is not confined to your own machine even though the page tells you to open http://127.0.0.1:3000.

The desktop preview is broken until you force the browser into phone mode

Two browser requirements sit on top of the install, and both produce the same symptom: a layout that looks wrong and a video that behaves oddly. On a desktop, press F12 to bring up the console and then Ctrl+Shift+M to switch the browser to phone mode, otherwise the preview will not look right. On a phone, the README names Via browser and Chrome as the browsers that work, and warns that other browsers may force video into fullscreen and break the display. What this cannot do is give you a responsive desktop layout, because there is no desktop design to fall back to; the project targets the mobile web only. The consequence is that reviewers see a broken page on their first visit, and that testing on a real handset depends on which browser the tester happens to have installed. Fixing the mode before filing anything is the difference between a real report and noise.

Only the gitee_pages build deletes the mock JSON from dist

The build scripts in package.json differ in what they leave behind. The plain build is `vite build`, and the uni-app target is `vite build --mode uni`, and the GitHub Pages target is `vite build --mode gp_pages`. The gitee target is different: `vite build --mode gitee_pages && pnpm run test-del-json`, and that second half runs `node node/remove-dist-json.js` from the node directory. In other words one cleanup step exists and one target uses it. None of the other build scripts in package.json runs that cleanup step, so the mock JSON may remain in their dist output. Choose the build command that matches your target before you publish anything.

The Makefile buildx target pins amd64 while the Dockerfile declares two platforms

Two build routes sit in the repository root with different targets. The Makefile reads the package name and version straight out of package.json with grep and sed, then offers docker-build, docker-buildx-build, docker-run, and a combined docker-build-run. The Dockerfile, meanwhile, declares `--platform=${BUILDPLATFORM:-linux/amd64,linux/arm64}` on both stages. The Makefile's buildx line does not follow that: it pins `--platform linux/amd64` and ends with `--load`. The buildx target therefore builds only for linux/amd64, while a comment above it shows an explicit command for linux/amd64,linux/arm64 with --push. The file also carries two warnings in comments: delete node_modules before testing a local image build because its presence can cause errors, and create your own buildx driver instance before using the buildx target.

The image build mixes pnpm and npm, and ships a third-party nginx base

The Dockerfile is short and worth reading line by line, because the details are where the surprises sit. The builder stage is node:20-buster, corepack is enabled, PNPM_HOME is set to /pnpm, and the dependency step is `pnpm install` followed by `npm run build`. Two package managers in one stage is not an error, since the script is simply invoked with npm, but it does mean the image resolves dependencies from pnpm-lock.yaml while a local reader following the README runs `npm install` and gets a tree npm resolved itself. The runtime stage is not nginx from Docker Hub: it is the `ghcr.io/rookie-luochao/nginx-runner:latest` image, with the built dist copied to /app. Because that reference is a floating latest tag rather than a pinned digest, the nginx configuration serving your static files can change under a rebuild without any change in this repository. What you cannot verify from the Dockerfile is what that base image actually ships.

A non-commercial notice sits next to a GPL LICENSE file and a 2024 release line

The licensing story has two halves and they do not line up. The page states that the project is only for learning and research and must not be used for commercial purposes, and the repository also ships a LICENSE file linked as GPL. Those are different grants, and nothing in the repository reconciles them, so anyone planning to build on this code has to decide which statement governs rather than assume the licence file settles it. The release line compounds the uncertainty. The tags run v1 on 2024-02-29 with a note about packaging an app with uniapp, then v1.0 on 2024-03-29 and v1.1 on 2024-04-01, while package.json still reads version 1.1.0 and the most recent commit is dated 2026-07-21. The project also describes itself as being in early development with new features being added. The consequence is that a clone gives you two years of work past the newest tag, untagged and unreviewed as a release.

Editorial conclusion

Use this repository to study how an infinite short-video feed is put together in Vue, as the six companion write-ups suggest, and to read a Pinia store driven entirely by intercepted requests. Do not treat it as a working Douyin client, a source of real content, or a base for a commercial app, because the project states it is for study and research only while shipping a GPL LICENSE file beside that notice. Before you start, confirm you can clone with git rather than download a zip, that you have a browser that will honour phone mode without forcing video fullscreen, and that you read the deployment build you actually want, since only the gitee_pages script runs the step that removes JSON from dist.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. zyronon/douyin on GitHub