The mesh2motion Docker image runs the dev server, and rewrites your Vite config on the way

The container starts the dev server, not the build

The Dockerfile ends with CMD ["npm", "run", "dev"], which is the same command the README gives for local development. The production build described one section earlier, npm run build, which writes a dist folder of static files, is never invoked in the image. So the docker-compose path gives you a development server in a container, with hot reload and all, and the dist output it can produce is left on the host. The port mapping makes the same point twice. Compose publishes 3000 on the host to 5173 inside the container, which is where Vite serves, while the Dockerfile declares EXPOSE 3000, a port nothing in the container listens on. Compose also sets container_name to mesh2motion-app and restart to unless-stopped, so the container comes back after a reboot.

The image edits vite.config.js while building

One line in the Dockerfile changes your source tree before anything installs:

RUN sed -i "s/open: !isCodeSandbox/open: false/" vite.config.js

The Vite config therefore ships with a sandbox flag, and the container build rewrites it in place so the dev server will not block on a code sandbox. If you mount a working copy into a container, that edit applies to your files. Two comments sit around it. One explains that you can comment the COPY out and clone instead, and the replacement it offers is a RUN git clone of https://github.com/scottpetrovic/mesh2motion-app.git into /app, which is a fork under a different account rather than this repository. The other suggests uncommenting apk add git for that route. On the runtime side the image is pinned to node:24.11.0-alpine, while the README only says the author uses 24 and that other versions probably work fine, and a .nvmrc sits in the repository root.

Export is GLB only, yet an FBX exporter is a dependency

The usage flow states the format limit twice, once on the way in and once on the way out: import currently supports only GLB and GLTF, and export currently supports only GLB and GLTF. The dependency list says something different in spirit. Alongside three, file-saver, jszip and tippy.js, the runtime dependencies include @comfyorg/fbx-exporter-three, an FBX exporter for three.js. Nothing in the README explains what that package is for, whether it is reachable from the user interface, or whether it is a leftover from an intended FBX path. The other three runtime dependencies are easier to place: file-saver for downloads, jszip for packaging exported files, and vite-plugin-glsl for shader support inside the built site. If your pipeline needs FBX, check the code rather than the documentation, because the documentation says the format is not offered.

The package is model-motionizer at version 0.0.0

There are no GitHub releases, and the manifest carries name model-motionizer, private true, version 0.0.0. So the name in package.json is not the name of the repository, and the version is a placeholder that has never been bumped. Release notes do exist, just not in the repository: the README points at a marketing site, mesh2motion.org, as the place that explains features and release notes, and at app.mesh2motion.org as the live application. Anyone automating a dependency on this project has nothing versioned to pin, so the practical unit is a commit. The scripts give the same impression of a project still being assembled: dev, build, lint, lint:fix, test, test:ui and test:coverage, with vitest, eslint and vite all in development dependencies and only the rendering libraries in the runtime list.

Wrangler is a runtime dependency with no deployment notes

The dependency list contains wrangler at version 4.77.0, and it sits in dependencies rather than devDependencies, next to three and jszip. The repository root carries wrangler.jsonc. Taken together those two files describe a Cloudflare Workers deployment target, yet no section of the README mentions Cloudflare, Workers, or wrangler. The documented paths are three: npm run dev for local work, npm run build producing a dist folder of files to serve to the web, and docker-compose up -d. If your hosting target is Workers, the configuration is there and undocumented; if it is not, the dependency is installed on every npm install for no stated reason. This is the same pattern as the FBX exporter, and worth checking before you either rely on it or remove it.

The Blender sources are in a second repository

Many of the 3D files were originally created in Blender, and that includes the models, the rigs and the animations. Those source files are not stored here. The stated reason is size: keeping large animation files out stops this repository from becoming too large, so only the final compressed GLB files are committed, and the Blender originals live at Mesh2Motion/mesh2motion-assets. They are also not needed to build or run the application, so a plain contributor can ignore the split entirely, and the README only points people at it if they want to contribute more animations. Two other files sit outside the main documentation as well. Video previews are generated by a separate tool inside the web app with its own README under src/preview-generator, described as more of an internal tool that the main page deliberately does not cover, and the repository also carries TESTING.md and CONTRIBUTOR.md that the README never links to.

MIT for the code, CC0 for the art, nothing in the metadata

The licences section splits the repository in two. The code and the platform are under what the README calls the very permissive MIT license, and the art assets, meaning the 3D models, the rigs and the animations, are under CC0, with the stated aim of making everything as open as possible to remix, change and build upon. The root carries LICENSE-MIT.MD and LICENSE-CC0.MD to match. The repository's licence metadata field, however, carries no value, so a tool reading the API rather than the README sees an unlabelled project. The split is also not itemised: the README names models, rigs and animations as the CC0 side, and the tree holds other assets such as a svg logo, a png screenshot and a static directory without saying which side of the line they fall on.

Three test scripts, two extra files, no testing section

Testing is configured and undocumented. The manifest defines test as vitest, test:ui as vitest with the ui flag, and test:coverage as vitest with the coverage flag, with vitest.config.ts at the root and @vitest/ui and @vitest/coverage-v8 both installed as development dependencies. jsdom is installed too, which points at a DOM testing environment. None of that appears in the README, which instead points you to in-application instructions for using the tool. Two documentation files sit in the root that the README never mentions either, TESTING.md and CONTRIBUTOR.md, so the guidance you would want about running the suite and about contributing probably lives there. Read those two before you file anything, since the visible README covers installing, building, Docker, previews, assets and licensing, and stops there.

Editorial conclusion

Mesh2Motion suits someone who wants to see what the browser based rigging flow does before committing to it, since the live application and the marketing site are both public and the code is MIT with CC0 art assets you can remix. For production, treat the repository's Docker instructions as a development convenience rather than a deployment path, because the image starts the dev server, publishes Vite's port rather than the one it exposes, and edits your config file while building. Use npm run build and serve the dist folder yourself if you care about what you ship. Three things to settle before contributing. Import and export are GLB and GLTF only, so a pipeline that needs another format has to convert outside the app. The Blender source files are in a second repository, not this one. And there are no tagged releases and the manifest version is 0.0.0, so track the commit date rather than a version number when you depend on it.

Frequently asked questions

Official sources

1. Issues
2. Mesh2Motion/mesh2motion-app on GitHub
3. README