Drop hero_admin_lib alias — standardize on hero_website_lib #5
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_website_framework#5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Issue
There is exactly one crate in this repo:
crates/hero_website_lib/. Buthero_proc/Cargo.toml:49declares it as:hero_osisdoes the same. Two names for the same crate makes the framework's surface confusing and means searching the codebase for one name misses half the consumers.Decision needed
Two options:
A. (Recommended) Drop the alias. Everyone imports
hero_website_lib. Single name, single search, simpler skills. Action items:hero_proc/Cargo.tomland source — rename aliashero_admin_lib→hero_website_lib.hero_osis/Cargo.tomland source — same."hero_admin_lib").hero_website_framework/README.md: "The crate is namedhero_website_lib. Older code may alias it ashero_admin_lib— drop the alias on next touch."B. Actually split. Extract an
hero_admin_libsub-crate fromhero_website_libcontaining only admin-surface code (admin templates, auth, /admin/rpc dispatch). Public website code (blog, docs, contacts) stays inhero_website_lib. Justification would be: admin-only consumers don't want public blog routes compiled in. But: the framework is small enough today that the compile-time saving is negligible, and the public/admin split is fuzzy.My recommendation: option A. Cleaner, fewer moving parts. If a split is ever needed later, do it then with a real reason.
Comment with your call.
Acceptance
hero_admin_libreturns zero hits (or all hits are in thehero_website_framework/README.mdhistorical note).cargo buildof hero_proc and hero_osis still succeed.Related
hero_rpc scaffold) #54Parent / context tracker: hero_skills#262 — read it before starting work on this issue. Locked decisions, reference materials, and execution order live there. Iterate via comments here; consolidation passes on the body only after feedback settles.
Closing — wrong premise
I drafted this from a stale snapshot of the repo. On latest
development,hero_admin_libandhero_website_libare two intentionally separate crates with different purposes:hero_admin_libhero_proc_admin,hero_osis_adminhero_website_libdemo_websiteonly (inside this repo)Original issue was based on
hero_proc/Cargo.toml:49usinghero_admin_lib = { git = ... }which I (wrongly) assumed was an alias. It's the real crate.Closing this. No alias to drop. The split is correct as-is.