3D_Magnetic_Pieces has a stop script in the readme and not in the tree

Seven models, twelve shapes, and two age ranges that disagree

The catalogue is small enough to read as a table and specific enough to be useful. Seven models across five themes, with difficulty, age range, piece count, step count and whether the model is flat or three-dimensional. Four of them are flat, which is what a real magnetic-tile set makes easy, and three are genuinely three-dimensional. The flagship house is the outlier at twenty-nine pieces over nine steps against a five-piece, four-step car, so the difficulty curve is not linear in piece count. The age column is where the documentation disagrees with itself: the Chinese section describes the site as designed for children aged three to six and their parents, while the catalogue includes a castle entry marked for ages six to twelve and the flagship house for five to ten. Twelve shapes are supported, from the square and rectangle through five distinct triangles to a trapezoid, rhombus, pentagon, hexagon, sector and semicircle, which is a reasonable approximation of a real tile set rather than a purely rectangular grid.

Two script names, one command, and it binds every interface

The package scripts contain a small duplication that is worth naming because of what it reveals about the rest of the configuration. The development command and the start-site command are byte-identical, and both of them are the bundler in development mode with three specific flags: bind to all interfaces rather than loopback, use a non-default port, and fail rather than choose another port if that one is taken. The non-default port is why the readme tells you to open a specific address rather than the usual one.

# Install dependencies
npm install

# Start the website on port 5174
npm run start-site

# Type-check and create a production build
npm run build

The strict-port flag is why the Windows launcher can meaningfully check whether something is already holding it. And binding to all interfaces means the development server is reachable from every network the machine is attached to, which is convenient for testing on a tablet, which this project explicitly supports, and is a thing to be aware of before you start it on shared or untrusted wifi.

The documented stop script is not in the repository

The one-click startup section for Windows tells you to double-click a launcher with a .cmd extension, describing what it does: check the port, install missing dependencies, start the development server and open a browser. It then tells you to run a second script with a different name to stop the service. Now look at the top-level listing. There is a launcher with a Chinese name and a .bat extension, an underscore-prefixed internal batch file, and a PowerShell helper for waiting and opening. There is no .cmd file anywhere in that listing, and there is no stop script at all. So the documented workflow names two files and the repository appears to contain one of them under a different extension, with the second possibly living inside the internal helper. That is the kind of gap that costs a first-time contributor fifteen minutes, and it is also the kind of thing a two-minute commit would fix by renaming a file.

Four deployment targets in the tree, three in the readme

The deployment section exists because of one architectural choice: the application uses a client-side router, so a static host must serve the index file as a fallback for unknown paths, or every route except the root returns a not-found. The readme then gives you the mechanism per host. For one host, a configuration file in the repository supplies the rewrite rule. For another, a different configuration file supplies the redirect rule. For a plain web server, three lines of configuration doing the standard try-files dance. The repository tree contains all three of those files and a fourth target the readme does not mention: a Cloudflare configuration file in JSON-with-comments form, plus the matching build plugin in the development dependencies. So the app is prepared for four hosts and documented for three, and the underlying requirement, a single-page fallback, is the same everywhere. If you are deploying somewhere else, that one requirement plus the port number is all you need to know.

A three-step standalone build that inlines the whole app

The tree contains a second build pipeline that the readme does not document, and it is the more interesting of the two. There is a standalone entry HTML file, a separate bundler configuration for it, and a plugin whose purpose is to inline a single module graph into one file. There is an archiver in the development dependencies, which is what would zip the result, and three separate scripts named for building it, packaging it and verifying it. The third one is the detail worth stopping on: a verification step that runs after packaging implies someone wanted to check the artefact rather than trust the build. For a project aimed at families and teachers, that is a sensible thing to want. It also means a standalone single-file build, which is exactly the shape that works from a USB stick, an email attachment or a school intranet with no server, and none of which the readme mentions.

Two dated working directories are committed alongside the source

The top-level listing includes two directories named after dates, one for an audit and one for research, both from late July 2026, sitting next to the source directory and a server directory. There is also a configuration directory for a model vendor's tooling, and an index file for the standalone build. Read as a whole, the repository is not a clean source tree: it contains what look like working artefacts from a specific week's activity. That is completely normal for a project built in public over a few months, and it is also the kind of thing that makes a repository harder to navigate than it needs to be. The server directory is the one to look at twice, because a project the readme deploys as static files should not need a server, so either it serves the development environment or it hosts something the readme has not described.

The roadmap leaves a multilingual interface undone in a bilingual readme

The roadmap is a useful honesty check because it is specific. Four items are done: local favourites, saving build progress in browser storage, the magnetic-tile learning centre, and a desktop design system. Eight are not, and among them three are worth pulling out. Real photographic assets of actual magnetic tiles is still open, which means everything you see on screen is rendered geometry rather than a photograph of a product, and that is a deliberate and defensible choice for a rendering-heavy browser app. A multilingual interface is open, even though the readme itself is written in both English and Chinese and the repository carries two launcher filenames in Chinese. And user-uploaded models is open, so the catalogue of seven is entirely curated, which is what makes the validation engine meaningful but also what limits the platform to what one person has drawn.

The editor is desktop-only and the readme says so plainly

The responsive section is unusually honest, because it distinguishes the two halves of the product. The learning site is responsive across three form factors: a desktop layout up to about fourteen hundred pixels wide with shared navigation, a mobile layout built around a three-hundred-and-ninety-pixel viewport with fixed bottom navigation, and a tablet layout around seven-sixty-eight pixels. Then one sentence settles the rest: the professional editor is intentionally optimized for desktop use. So a parent on a phone gets the tutorials and a model browser, and a contributor on a laptop gets the authoring workspace. The testing story matches that split. There is a unit suite and an end-to-end suite driven by a browser automation tool with its own configuration file at the root, and the editor section lists unit, integration, route, visual-regression and end-to-end coverage, which is a lot of layers for a single-file Three.js app and suggests the rendering is tested rather than assumed.

Editorial conclusion

This project fits a family or a teacher who wants step-by-step magnetic-tile building in a browser with no account and no app, and fits a contributor who wants to add models to a catalogue with a validation engine behind it. It does not fit a tablet-first deployment, because the authoring editor is documented as desktop-only, and it does not fit anyone who needs the physical products pictured, since real image assets are still an unchecked roadmap item and the tiles are rendered geometry. Before you build on it, read the deployment section properly, because the application uses a client-side router and a static host without a fallback will 404 on every route except the index, and note that the shipped package is private, so there is nothing to install from a registry.

Frequently asked questions

Official sources

1. fengyanhao/3D_Magnetic_Pieces on GitHub
2. License: MIT
3. Project website
4. README
5. Releases