# Trim Unused Modules > Propose disabling modules in src/modules.ts that the current standalone project does not actually use. Intended to be offered after the user adds a new custom module, because a fresh create-mercato-app scaffold enables every built-in module (classic mode) and that is rarely what the project actually needs in production. - Skill: `open-mercato/trim-unused-modules` (Agent Skill) - Install (CLI): `npx skillmds@latest add open-mercato/trim-unused-modules` - Raw SKILL.md: https://api.skillmd.com/api/skills/open-mercato/trim-unused-modules/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: open-mercato (https://skillmd.com/u/open-mercato) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/open-mercato/trim-unused-modules --- # Trim Unused Modules A fresh `create-mercato-app` scaffold enables every built-in Open Mercato module by default (classic mode) so that the app "just works" on day one. Once the user has added a new custom module and knows what they actually want to build, many of those defaults are dead weight — they slow down `yarn dev`, pollute the navigation sidebar, pull in unnecessary dependencies, and show the user features that will confuse their end users. Invoke this skill when: - The user just added a new module to `src/modules.ts` via `yarn mercato module add …` or by hand-creating `src/modules//`. - The user asks "which modules do I really need?" or "how do I slim down the app?" - You notice during another task that `src/modules.ts` still has every built-in module enabled AND the user's business domain clearly does not need some of them (e.g. a blog-only app with `sales`, `catalog`, `currencies`, `workflows`, `integrations`, `data_sync` all active). ## Workflow 1. **Never disable modules silently.** Always confirm with the user via `AskUserQuestion` before editing `src/modules.ts`. 2. **Read the current module list.** Parse `src/modules.ts`. For each entry: - Record the module `id` and its source (`@open-mercato/core`, `@open-mercato/`, `@app`). - Flag entries with `from: '@app'` as **user modules** — never propose disabling these. - Flag entries with `from: '@open-mercato/…'` as **built-in modules** — eligible for review. 3. **Gather usage signals.** For each built-in module, check: - Is the module's feature ID referenced in `src/modules/**/acl.ts` or `src/modules/**/setup.ts`? - Is a type/name from the module imported anywhere in `src/**`? - Does any subscriber/worker declaration in `src/modules/**` reference an event ID the module owns? - Does the backend sidebar config reference routes from the module? - Is the module listed as a hard dependency in any enabled integration provider's manifest? Record yes/no per signal. If ALL signals return "no", mark the module as a **removal candidate**. 4. **Mark hard-required modules.** Never propose disabling modules that other parts of the framework rely on by convention. The baseline set that should stay enabled in almost every project: - `auth`, `customer_accounts`, `entities`, `configs`, `organizations`, `tenants`, `users` Include any module that another enabled module's `setup.ts` declares as a dependency. 5. **Present the proposal.** Use `AskUserQuestion` with a multi-select list of removal candidates. Include: - The module ID and a one-line description of what it does. - Which usage signals came back negative. - Whether disabling it will require running DB operations (e.g. dropping its tables — NOT something this skill performs; flag it so the user knows). 6. **Apply the user's choices.** For each module the user confirms: - Remove the entry from `src/modules.ts`. - Do NOT delete files from `node_modules/@open-mercato/*` (packages stay installed — disabling just means the app no longer loads them). - Do NOT drop the module's database tables. Data removal is a separate, destructive operation that the user must request explicitly. - **If `dashboards` is one of the disabled modules, you MUST also update `src/app/(backend)/backend/page.tsx`** so it no longer renders ``. Replace the body with a `redirect(...)` to the first backend page the user can reach — prefer the main sidebar group (e.g. `/backend/customers/people`) and fall back to `/backend/profile` if nothing else is enabled. Without this edit, `/backend` will crash at build or request time because the removed module no longer ships `DashboardScreen`. Commit this edit in the same change as the `src/modules.ts` edit. 7. **Re-run the generator.** After the edit: ```bash yarn generate ``` This regenerates `.mercato/generated/*` without the disabled modules and triggers the best-effort structural cache purge. 8. **Report.** Print a short summary: - Which modules were disabled. - Which modules were kept (and the signal that kept each). - Reminder that package dependencies are still installed and module tables still exist; if the user wants to fully remove a module, they must uninstall the package and manually drop its tables. ## Constraints - NEVER remove a `from: '@app'` entry. - NEVER remove `auth`, `customer_accounts`, `entities`, `configs`, `organizations`, `tenants`, or `users`. - NEVER delete files from `node_modules/` or from `src/modules//` on behalf of the user — only edit `src/modules.ts`. - NEVER drop database tables. - If the user answers "no" to every removal candidate, exit quietly and note that classic mode is preserved. ## When NOT to run this skill - In a monorepo development environment (`apps/mercato/src/modules.ts`) — the monorepo deliberately keeps every module enabled for framework development. - On an imported ready app (`--app` or `--app-url`) — those snapshots are curated by their authors. - During a `yarn dev` run — disabling modules while the server is live can cause transient errors. Ask the user to stop `yarn dev`, run the skill, then restart.