packages/service (@otta-sh/service) was deleted when the commerce service was folded into the plugin, along with packages/store-postgres. Two of the four rules in .dependency-cruiser.cjs were updated to stop naming it; two were not, and still hardcode service in their to.path regex and/or their comment.
Still stale
-
domain-is-io-free (~line 8)
- comment: "...and no dependency on adapter/service/plugin packages (DEVELOPMENT.md §3)."
to.path tail clause: ^packages/(store-[^/]+|service|plugin|payments-[^/]+)/
-
store-emdash-is-sandbox-clean (~line 190)
- comment: "Sibling adapters, the service and the payment packages are likewise named in all three spellings..."
to.path names service in three separate clauses:
node_modules/@otta-sh/(...|service|...)(/|$)^@otta-sh/(...|service|...)(/|$)^packages/(service|payments-[^/]+|admin-react|plugin)/
Why it matters
This is documentation rot, not a correctness bug: a ban on a package that does not exist can never fire, so the rules behave identically with or without the clause. But it misleads a reader into thinking @otta-sh/service is still part of the workspace, and it is the same rot already cleaned out of plugin-is-sandbox-clean and store-emdash-no-console-react.
Suggested fix
Drop service from both rules' regexes and reword both comments, matching how it was done in the other two rules. Note the deliberate decision made there: a reintroduced service package should be forbidden on the day it is created, so if the clauses are removed, the family-level bans (store-[^/]+, payments-[^/]+) should be checked to confirm nothing is left unguarded, or a broad lookahead added instead.
Both rules are exercised by packages/plugin/test/depcruise-boundary.test.ts, so any change here should come with the matching cases in that suite.
packages/service(@otta-sh/service) was deleted when the commerce service was folded into the plugin, along withpackages/store-postgres. Two of the four rules in.dependency-cruiser.cjswere updated to stop naming it; two were not, and still hardcodeservicein theirto.pathregex and/or their comment.Still stale
domain-is-io-free(~line 8)to.pathtail clause:^packages/(store-[^/]+|service|plugin|payments-[^/]+)/store-emdash-is-sandbox-clean(~line 190)to.pathnamesservicein three separate clauses:node_modules/@otta-sh/(...|service|...)(/|$)^@otta-sh/(...|service|...)(/|$)^packages/(service|payments-[^/]+|admin-react|plugin)/Why it matters
This is documentation rot, not a correctness bug: a ban on a package that does not exist can never fire, so the rules behave identically with or without the clause. But it misleads a reader into thinking
@otta-sh/serviceis still part of the workspace, and it is the same rot already cleaned out ofplugin-is-sandbox-cleanandstore-emdash-no-console-react.Suggested fix
Drop
servicefrom both rules' regexes and reword both comments, matching how it was done in the other two rules. Note the deliberate decision made there: a reintroducedservicepackage should be forbidden on the day it is created, so if the clauses are removed, the family-level bans (store-[^/]+,payments-[^/]+) should be checked to confirm nothing is left unguarded, or a broad lookahead added instead.Both rules are exercised by
packages/plugin/test/depcruise-boundary.test.ts, so any change here should come with the matching cases in that suite.