react-crm: a CRM front end that runs on mock service worker data

The gap this fills is a CRM interface with nothing behind it

The repository presents itself as a reusable CRM project for real-world business based on React, Redux and Material-UI. What it actually ships is the front end. There is no server component, no persistence layer and no authentication service described anywhere in the project documentation. That is not an oversight hidden in the source, it is the stated design: the getting started section describes yarn dev as a Vite plus MSW mock API running on http://localhost:5173. MSW stands for Mock Service Worker, and it intercepts network calls in the browser so the interface can perform reads and writes against canned responses. The July 2026 change log entry lists the scope that was added: full CRUD for Users, Products, Orders and Cart, a checkout to payment to shipment pipeline, dashboard analytics from live data, route-level code-splitting, production MSW, real Storybook stories, and a Vitest plus Testing Library test setup. That is a wide surface for a demo, and it is why this repository is worth reading even if you never ship it. For a team deciding whether to build its own CRM front end, the value sits in the screen inventory and the state patterns rather than in reusable server code.

The live demo is a different build from the master branch

The live demo link points at react-demo-v6.harryho.org, and the documentation states plainly that the demo is just a proof of concept which does not have a back-end API and does not have all the features of master branch. That sentence matters for anyone evaluating the project from the outside. The screens you can click through online are a subset of the code on master, so the July 2026 CRUD work and the route-level code splitting are likely not visible there. The project also keeps an older demo, react-demo-v4.harryho.org, built on React 16 and MUI 4, with the source kept on the r16m4 branch. So there are at least three things to compare: the current master source, a reduced online demo, and an archived generation from the React 16 era. The history is also visible in the change log. Entries run from May 2018, when the json-server branch was created, through December 2018, May 2020, June and December 2024, April 2025, June 2026 and July 2026. Reading those lines in order explains why the README still mixes product language with tooling history.

MSW 2 replaced json-server, and the old branch is frozen

The most interesting engineering decision in the change log is the replacement of json-server with MSW 2 service-worker mocks and a typed fetch client, which the June 2026 entry describes as a platform uplift and domain rework. The earlier entries explain why the old approach was abandoned. The May 2018 note records that the json-server branch was created as the master which used Json-Server as fake API, and that considering the hiccup of setting Json-Server up and maintenance, it would be replaced by a fake service offering a read-only fake API, and that the branch would no longer be updated. The December 2018 entry states the consequence plainly: the new master does not rely on Json-Server as fake API, it has only a readonly fake API, which means any new or updated data will be stored to any physical file and all test data will be rolled back after system restart. The service worker approach changes the failure mode. Instead of a second process on the machine, the mocks live in the browser and intercept requests, so the same code path that would call a production API runs against recorded responses. The repository layout backs this up: a public directory for the mock worker files, an init-msw script that writes them, and a service worker entry that the dev command starts.

Node 22 and Yarn are enforced, and mixing package managers will hurt

The prerequisites are unusually specific for a demo, and they exist because the toolchain moved. Node.js 22 or newer is required by Vite 8 and is enforced through the engines field, and the quick check given is that node -v should report v22.x or newer. Yarn 1.22 or newer is required, the repository ships a yarn.lock, and the documentation says not to mix with npm or pnpm. The version floors cover TypeScript 5.9, React 19.2, MUI 7.3, react-router 7.18, Vite 8.1, Storybook 10.5, MSW 2.3 and Vitest 3.2. The getting started sequence is short, and every command below comes straight from the project documentation:

git clone https://github.com/harryho/react-crm.git
cd react-crm
yarn install

yarn dev             # Vite + MSW mock API on http://localhost:5173
yarn storybook       # Storybook on http://localhost:6006
yarn test            # Vitest unit tests
yarn build           # tsc + Vite production build

After yarn install you should see the dev server on http://localhost:5173 serving an interface that already answers requests through the mock layer, and Storybook separately on http://localhost:6006.

Each yarn script maps to one tool, and the build runs tsc first

The scripts block in package.json is where the toolchain becomes concrete, and it is worth reading before you start because the names do not always match the README wording. The dev script is vite, build is tsc and vite build, and there is a separate compile script that runs tsc on its own, so type errors surface without a bundling step. The storybook script runs storybook dev -p 6006, which is why the documentation gives port 6006 for Storybook and port 5173 for the app, and build-storybook produces the static Storybook output. The init-msw script runs msw init public/, which writes the worker file into the public directory that the Vite dev server serves. The test scripts are vitest run for a single pass and vitest for watch mode, and test-storybook runs the Storybook test runner against your stories. Seeing these as one table clarifies the intended workflow: the app, the component workshop and the test suite are three separate entry points into the same codebase, each with its own command.

  "scripts": {
    "compile": "tsc",
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview",
    "storybook": "storybook dev -p 6006",
    "build-storybook": "storybook build",
    "init-msw": "msw init public/",
    "test-storybook": "test-storybook",
    "test": "vitest run",
    "test:watch": "vitest"
  },

The Dockerfile contradicts the toolchain it has to build

The repository contains a Dockerfile and a config directory holding an nginx.conf, which suggests a container deployment path. The file itself does not agree with the prerequisites. The build stage uses node:12-slim as its base image, copies the source in, then runs npm install and npm run build. Node 12 is far below the v22 floor the documentation requires, and npm is the package manager the documentation rules out. The run stage is nginx:alpine with the built output copied into the static root and config/nginx.conf placed as the default site configuration. The comments in the file give the intended commands, docker build . -t rc-prd:2.0 and a run that publishes port 8080 onto port 80. The likely explanation is that the Dockerfile was not touched during the June 2026 upgrade that moved the project to Vite 8 and React 19.2, while the scripts and the dependency versions were. That makes it a documentation and reference artefact rather than something to copy: the same package.json would fail to build on node:12, and the yarn.lock is what the install step should be using.

FROM node:12-slim AS node
LABEL author="Harry Ho"
WORKDIR /
COPY . .
RUN npm install
RUN npm run build

Package metadata still carries the old project identity

The package.json is internally consistent with a Vite and Storybook template rather than with the CRM it now contains. The name is react-demo-v6 and the version is 6.5.1, the description calls it a boiler template to get up and running quickly with React, Storybook, Vite and TypeScript, and the repository and bugs URLs both point at chromaui/intro-storybook-react-template, a Storybook template that has nothing to do with a CRM. The package is marked private, which is correct for an application, and the licence is MIT. There are two version details worth checking before you rely on them. The README lists react-router 7.18 among the prerequisites, while the dependencies block specifies react-router at version 8.3.0, so the documented floor is lower than the installed one. And @iconify/react is pinned to the tag latest, which means a fresh yarn install can pull a different icon package than the one the code was written against. The dependencies also include @toolpad/core, apexcharts with react-apexcharts for the dashboard charts, dayjs for dates, react-helmet-async for document head management and simplebar-react for scrollbars. There is a genuine question about Redux, too. The repository description calls this a project based on React, Redux and Material-UI, and the topics list includes react-redux and thunk, yet the dependencies block contains no redux package at all. If you want the Redux version, check the source tree rather than the metadata.

Maintenance comes from the commits, not from any release

The repository has no GitHub releases, so there is no version history to cite beyond the change log entries in the README and the version field in package.json. It is not archived, and the last push was on 2026-10-14, which places it in active work rather than in an abandoned state. The pace is uneven by design, since this is a portfolio and reference project rather than a library with dependents: the July 2026 entry describes a large feature sweep across CRUD screens and a checkout pipeline, while June 2026 was a dependency bump and a rework of the mocking layer. For a team considering adoption, that means the upgrade cost is dominated by dependency churn rather than by API changes in the project itself, because there is no published API surface to break. The MIT licence carries no copyleft obligation and no per-instance distribution requirement for the code, though it is not legal advice and your own reading of the LICENSE file in the repository is the last word. The repository also carries an .eslintrc.cjs, a .storybook directory, a vite.config.ts and separate tsconfig.json and tsconfig.vite.json files, which tells you the project expects you to keep linting and type checking green as you edit it.

Editorial conclusion

Adopt react-crm if you want a typed CRM interface to study or copy, with CRUD screens for Users, Products, Orders and Cart, a checkout to payment to shipment flow, and Storybook stories you can lift into another project. Do not adopt it as a production CRM: there is no back end, the published demo lacks the master branch features, and the Dockerfile still builds on node:12 with npm while the toolchain requires Node 22 and Yarn. Before you copy anything, run yarn install and yarn dev to see the mock API in the browser, then read the package.json scripts, since the file still carries a react-demo-v6 name and a repository URL pointing at an unrelated Storybook template.

Frequently asked questions

Official sources

1. harryho/react-crm on GitHub
2. Issues
3. License: MIT
4. README