feat(types): extract shared DTOs into mokosh-types workspace crate (PMS-129) #67
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/pms-129-mokosh-types"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
auth,contacts,tenants,tickets,time_tracking) fromsrc/modules/<m>/models.rsinto a new workspace cratecrates/mokosh-types. Bothmokosh-serverand (in a follow-up PR)mokosh-clientsdepend on this crate, replacing the manual copy-paste sync described indev-docs/codebase-state.mdcross-cutting issue #12.src/modules/<m>/models.rsbecomes a 1-line re-export (pub use mokosh_types::<m>::*;) so everysuper::models::*path inside the consuming module continues to resolve unchanged. Zero type-signature or logic changes; pure relocation.mokosh-typesdeps are the union of the imports the five model files actually use:serde,chrono,uuid,validator,rust_decimal. Nosqlx, noaxum, no async runtime so the WASM client can consume it without server-only transitives.Why now
The project doc (
dev-docs/client-server-integration.md) recommended(b) drift CI today, (a) shared crate when a fifth shared module is added. The fifth (time_tracking) landed 2026-06-03; recent server work (PMS-126 tracing, PMS-127 pagination) drifted the trees by ~130 cumulative lines. Doing the shared-crate move now beats first reconciling drift back to the clients repo before adding a CI check.Follow-up
mokosh-clientsneeds a matching PR to delete its fivemodels.rsfiles and addmokosh-types = { path = "../mokosh-server/crates/mokosh-types" }(or via a workspace dep). That work is intentionally NOT in this PR.Test plan
cargo fmt --all --checkcargo clippy --all-targets -- -D warningscargo check --all-targetsCloses PMS-129.