Module wheels declare empty 'dependencies' but their .tsx imports lucide-react/sonner directly; Makefile never runs sm host sync-js-deps

[antosubash]

Summary

There's a designed-for mechanism for modules to declare extra npm deps (sm host sync-js-deps reads each module wheel's package.json dependencies, then npm install --workspaces them), but in the published 0.0.7 packages it doesn't work end-to-end:

1. Every built-in module's wheel ships a package.json with \"dependencies\": {}, even when its .tsx files clearly import third-party packages.
2. The scaffold's Makefile doesn't call sync-js-deps from make install or make dev. Even if (1) were fixed, a fresh-clone-to-running-host flow would still skip the install.

Net effect: a fresh sm new host on 0.0.7 errors at vite resolution time on lucide-react and sonner, with no built-in path to fix it short of hand-editing client_app/package.json.

Reproduction

uvx --from simple_module_cli sm new my-app --db sqlite --preset standard -y --no-install
cd my-app && cp .env.example .env && make install && make migrate && make gen-pages
cd client_app && npm run dev

Vite output (relevant lines):

Error: The following dependencies are imported but could not be resolved:
 lucide-react (imported by .../site-packages/users/components/RolesTab.tsx)
 sonner (imported by .../site-packages/users/pages/Users/Edit.tsx)

Confirming the mechanism exists but finds nothing to install:

$ uv run python -m simple_module_hosting sync-js-deps --dry-run
INFO: Discovered module: Permissions (v1.0.0)
INFO: Discovered module: Users (v1.0.0)
INFO: Discovered module: Settings (v1.0.0)
INFO: Discovered module: Dashboard (v1.0.0)
INFO: Discovered module: Auth (v1.0.0)
No module JS dependencies declared.

collect_module_js_deps() only reads dependencies (per its docstring: "peerDependencies are host-provided singletons and must not be installed from modules") — and every module wheel has it empty.

Evidence — what users ships vs. what it imports

Module's wheel package.json (.venv/lib/python3.12/site-packages/users/package.json):

{
 "name": "@simple-module-py/users",
 "version": "0.1.0",
 "private": true,
 "peerDependencies": {
 "react": "^19.0.0",
 "react-dom": "^19.0.0",
 "@inertiajs/react": "^2.0.0",
 "@simple-module-py/ui": "*"
 },
 "devDependencies": {
 "@simple-module-py/tsconfig": "*"
 },
 "dependencies": {}
}

But the wheel's source imports:

• users/components/RolesTab.tsx → lucide-react
• users/pages/Users/Edit.tsx → sonner

Neither is in peerDependencies (so it's not "the host must supply them"), nor in dependencies (so sync-js-deps doesn't pick them up). They're effectively un-tracked.

Same shape in dashboard/package.json, permissions/package.json, auth/package.json — all with \"dependencies\": {}.

Proposed fix

Two edits, ideally landed together:

A. Modules declare what they import

Either:

A1. Have each module's package.json list the third-party packages it imports directly:

{
 "name": "@simple-module-py/users",
 ...
 "dependencies": {
 "lucide-react": "^X.Y.Z",
 "sonner": "^X.Y.Z"
 }
}

…and let sync-js-deps install them into the host workspace.

A2. (cleaner long-term) — Re-export the icons/toasts the modules need from @simple-module-py/ui so module .tsx files don't import upstream packages directly. Then modules only depend on @simple-module-py/ui (which they already do as a peer), and #114's missing-deps fix on the UI package solves this for free.

A2 is more in line with how the framework already treats @simple-module-py/ui as the canonical UI surface — and avoids version skew (one source of truth for which lucide-react is shipped).

B. Wire sync-js-deps into the standard install flow

Update the scaffolded Makefile:

 install:
 	uv sync
 	cd client_app && npm install
+	$(MAKE) sync-js-deps

 dev: gen-pages
 	@echo "Starting API and UI dev servers..."
 	$(MAKE) -j2 dev-api dev-ui

+sync-js-deps:
+	uv run python -m simple_module_hosting sync-js-deps --host-client-app=client_app
+
 gen-pages:
 	uv run python -m simple_module_hosting gen-pages --host-dir=client_app

Without (B), even a perfect (A1) doesn't help on a fresh clone — users hit the same vite error and have to know that an undocumented python -m simple_module_hosting sync-js-deps exists.

Workaround

cd client_app && npm install lucide-react sonner --save=false

Won't survive a lockfile regen.

Related

• @simple-module-py/ui imports 14+ npm packages but declares only @simple-module-py/i18n in dependencies #114 — @simple-module-py/ui's own missing deps. If A2 is taken, @simple-module-py/ui imports 14+ npm packages but declares only @simple-module-py/i18n in dependencies #114's fix subsumes most of this.
• @simple-module-py/ui exports map: './*': './src/*' can't resolve nested subpaths or extension-less imports #115 — exports-map fix for @simple-module-py/ui.
• Module-shipped .tsx pages need symlink + vite aliases + inline tsconfig boilerplate #73 (closed) — older symptom of the broader "module .tsx files live outside the host's npm tree" problem.

Environment

• simple_module_cli 0.0.7
• simple_module_users, simple_module_dashboard, simple_module_permissions, simple_module_auth 0.0.7
• simple_module_hosting 0.0.7 (provides sync-js-deps)

[antosubash]

Update — verified against 0.0.8 + bumped npm pin

After bumping @simple-module-py/ui to 0.0.8 in client_app/package.json (so #114/#115 fixes are actually loaded — see #119 for why the scaffold pin blocks this), the picture changes:

• lucide-react, sonner, next-themes, radix-ui, recharts, cmdk, etc. are now installed transitively, because @simple-module-py/ui@0.0.8 declares them as dependencies. So part (A) of this issue is already moot for the bundled modules — sync-js-deps doesn't need to install lucide-react/sonner after all, the UI package brings them along.
• But npm run dev still fails the same way, because vite's bare-import resolver walks UP from each importing file looking for node_modules. Module .tsx files live in .venv/lib/python3.12/site-packages/<mod>/, and there's no node_modules to be found by walking up from there until you'd hit ~/. The host's actual node_modules is in client_app/, a sibling of the venv.

Error: The following dependencies are imported but could not be resolved:
 @simple-module-py/ui/components/ui/button (imported by .../site-packages/users/components/RolesTab.tsx)
 lucide-react (imported by .../site-packages/users/components/RolesTab.tsx)
 ... (same shape as before)

So the underlying problem isn't "deps not installed" — it's "vite can't see the deps from where the file lives".

Confirmed working stopgap

Adding explicit aliases to the scaffold's vite.config.ts makes npm run dev resolve everything cleanly:

resolve: {
 dedupe: ['react', 'react-dom', 'react/jsx-runtime', 'react/jsx-dev-runtime'],
 alias: [
 { find: /^lucide-react\$/, replacement: path.resolve(__dirname, 'node_modules/lucide-react') },
 { find: /^sonner\$/, replacement: path.resolve(__dirname, 'node_modules/sonner') },
 {
 find: /^@simple-module-py\\/ui(\\/.*)?\$/,
 replacement: path.resolve(__dirname, 'node_modules/@simple-module-py/ui') + '\$1',
 },
 ],
},

This is functionally the same as what #73 (closed) hacked in via per-module symlinks — it just centralizes the indirection in the host's vite config. Either approach lets vite locate @simple-module-py/ui and friends from a .tsx file in .venv/.../site-packages/<mod>/.

Recommended path forward

I think (B) — wiring sync-js-deps into the Makefile — is no longer the load-bearing fix. The two real options are:

1. Tactical: ship the alias shape above in the scaffold's vite.config.ts template, building it dynamically from modules.manifest.json if more bare imports show up later. This unblocks today's flat scaffold.
2. Strategic: restructure sm new output to be an actual npm workspace per sm new should scaffold host + a working sample module in a uv/npm workspace, matching the framework repo's own layout #117, so module .tsx files are workspace members and vite's normal walk-up resolution works without aliases.

(2) is what the framework repo itself does, so it's the path of least surprise long-term. (1) is one PR to the CLI's vite-config template and unblocks every existing host immediately.

Module deps still worth tracking

The dependencies: {} finding in the original report is still true for the published users/auth/dashboard/permissions 0.0.8 wheels — sync-js-deps would still report "No module JS dependencies declared". Today this doesn't bite because @simple-module-py/ui carries the third-party deps. But if a module ever needs a JS package that isn't in @simple-module-py/ui (say, a chart lib not used by ui), it has nowhere to declare it that gets installed.

So the (A) part of this issue downgrades from "blocker" to "latent design gap" — worth fixing before someone hits it, not urgent.

[antosubash]

Fixed in #130.