SM017 diagnostic suggests creating package.json/tsconfig.json paths *inside .venv/site-packages*

[antosubash]

Summary

The SM017 startup diagnostic flags every wheel-installed module that ships pages/*.tsx and recommends creating files at paths inside the active virtualenv's site-packages. Those paths are write-once-throwaway (re-installing the wheel obliterates them, and uv sync --frozen will recreate them anyway), so following the suggestion is impractical and confusing.

Reproduction

Boot a freshly-scaffolded host (after working around the other issues):

⚠ SM017 [WARNING] Permissions: Module ships pages/*.tsx but has no tsconfig.json
 ↳ /Volumes/ext1/Sandbox/simple_module_chat/confident-lovelace-210ce5/.venv/lib/python3.12/site-packages/tsconfig.json
 ↳ Suggestion: Create /Volumes/ext1/Sandbox/simple_module_chat/confident-lovelace-210ce5/.venv/lib/python3.12/site-packages/tsconfig.json — without it npm won't treat the module as a workspace member and Vite may fail to resolve @simple-module-py/ui subpath imports

⚠ SM017 [WARNING] Permissions: Module ships pages/*.tsx but has no package.json
 ↳ ... (same shape, .venv path)

⚠ SM017 [WARNING] Dashboard: Module ships pages/*.tsx but has no tsconfig.json
 ↳ ... (same shape, .venv path)

⚠ SM017 [WARNING] Users: Module ships pages/*.tsx but has no package.json
 ↳ ... (same shape, .venv path)

(8 warnings total against Permissions, Dashboard, Users, Auth — i.e. every wheel-installed module that contributes pages.)

Why the suggestion doesn't make sense as written

For a wheel-installed module:

• site-packages/<module>/ is owned by the package manager (uv/pip). Adding files there is destroyed on reinstall, gets out of sync with uv.lock, and isn't tracked in any source repo.
• npm workspaces resolve packages relative to the root package.json's workspaces glob. Pointing them into .venv/.../site-packages/<module>/ cross-couples the JS tree to the Python venv layout — and the venv path is per-developer, per-OS, sometimes not even adjacent to the project (here: confident-lovelace-210ce5/.venv/...).
• The actual underlying problem (Vite not resolving subpath imports from wheel-installed .tsx files) is the same architectural issue covered partially in the closed Module-shipped .tsx pages need symlink + vite aliases + inline tsconfig boilerplate #73 and in @simple-module-py/ui exports map ('.', './*') doesn't cover ./components/*, ./layouts/* — vite can't resolve subpath imports from module pages #110 (filed alongside this one).

Possible fixes

A few options, depending on the intended architecture:

1. Drop SM017 for wheel-installed modules. Only warn for workspace modules under modules/<m>/, where package.json/tsconfig.json make sense. The current bare-path heuristic hits both source and wheel modules.
2. Stop shipping module pages from site-packages: have the install step (or a new sm host sync-pages command) copy/symlink the .tsx files into the host's client_app/ tree where Vite can natively resolve them. Then SM017 becomes irrelevant.
3. Rephrase the suggestion so it tells the user what to do at the host level (e.g. add an alias in vite.config.ts, register a workspace, or run sm host sync-js-deps if that's the intended fix), not asking them to write inside .venv/.

Source reference

The diagnostic message (literal text quoted above) is emitted from simple_module_hosting's diagnostics layer at boot — search for SM017 in simple_module_hosting/_phase_helpers.py / module diagnostics machinery.

Environment

• simple_module_hosting, simple_module_users, simple_module_dashboard, simple_module_permissions, simple_module_auth 0.0.6
• simple_module_cli 0.0.6

[antosubash]

Status in 0.0.7

The SM017 warnings no longer appear at boot in 0.0.7 — clean boot of a freshly-scaffolded host emits no SM017 lines. So the misleading suggestion path issue this filed against is gone.

The underlying frontend-resolution problem still bites, just from a different layer (vite, not the diagnostics layer) — see #110 which I've updated with the 0.0.7 reproduction. Closing this in favor of #110 unless you'd like to keep it open as a tracking item for the diagnostic itself.