hero_admin_lib unresolvable as a git dep on `development` — parked as `_old` during in-flight hero_theme/asset refactor #15

New issue

Open

opened 2026-06-17 14:29:51 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-06-17 14:29:51 +00:00

Member

Summary

On development, the server-rendered admin lib (package hero_admin_lib) can't be resolved as a git dependency:

error: no matching package named `hero_admin_lib` found
location searched: Git repository .../hero_website_framework?branch=development

It lives in crates/hero_admin_lib_old/ and is not in the workspace members, so cargo (which only resolves members of a git repo) can't see it. On main it is a normal member at crates/hero_admin_lib.

Root cause (corrected)

This is not a stray members omission — it is an in-flight refactor. Per 50602bd refactor: rename hero_admin_lib to _old, consolidate static assets at repo root, the crate was deliberately parked as _old while theme/assets are extracted into a hero_theme crate. Dev's source already imports it (crates/hero_admin_lib_old/src/assets.rs:212 → hero_theme::ThemeAssets::get(...), commented as "the hero_theme crate in hero_web_template").

Simply re-adding crates/hero_admin_lib_old to members does not work — the workspace then fails to resolve because hero_theme is not in [workspace.dependencies], and hero_web_template / hero_theme is not published yet:

error inheriting `hero_theme` from workspace root manifest's `workspace.dependencies.hero_theme`
`dependency.hero_theme` was not found in `workspace.dependencies`

So there is no clean fix that downstream can land; this needs the framework refactor to complete.

Impact

Downstream services that use the new admin lib must pin it to main until the refactor lands:

hero_slides (admin) → main
hero_code (Cargo.toml:85) → main
hero_cockpit pins development but ships no committed Cargo.lock / override, so a clean resolve hits the no matching package error above.

Ask

Once the hero_theme / asset refactor is complete (publish hero_web_template / hero_theme, add hero_theme to [workspace.dependencies]), restore hero_admin_lib as a workspace member at crates/hero_admin_lib (parity with main). A heads-up on the expected timeline would help us schedule flipping the downstream hero_admin_lib pins to development.

## Summary On `development`, the server-rendered admin lib (package `hero_admin_lib`) can't be resolved as a git dependency: ``` error: no matching package named `hero_admin_lib` found location searched: Git repository .../hero_website_framework?branch=development ``` It lives in `crates/hero_admin_lib_old/` and is not in the workspace `members`, so cargo (which only resolves members of a git repo) can't see it. On `main` it is a normal member at `crates/hero_admin_lib`. ## Root cause (corrected) This is **not** a stray `members` omission — it is an in-flight refactor. Per `50602bd refactor: rename hero_admin_lib to _old, consolidate static assets at repo root`, the crate was deliberately parked as `_old` while theme/assets are extracted into a `hero_theme` crate. Dev's source already imports it (`crates/hero_admin_lib_old/src/assets.rs:212` → `hero_theme::ThemeAssets::get(...)`, commented as "the `hero_theme` crate in `hero_web_template`"). Simply re-adding `crates/hero_admin_lib_old` to `members` does **not** work — the workspace then fails to resolve because `hero_theme` is not in `[workspace.dependencies]`, and `hero_web_template` / `hero_theme` is not published yet: ``` error inheriting `hero_theme` from workspace root manifest's `workspace.dependencies.hero_theme` `dependency.hero_theme` was not found in `workspace.dependencies` ``` So there is no clean fix that downstream can land; this needs the framework refactor to complete. ## Impact Downstream services that use the new admin lib must pin it to `main` until the refactor lands: - hero_slides (admin) → `main` - hero_code (`Cargo.toml:85`) → `main` - hero_cockpit pins `development` but ships no committed `Cargo.lock` / override, so a clean resolve hits the `no matching package` error above. ## Ask Once the `hero_theme` / asset refactor is complete (publish `hero_web_template` / `hero_theme`, add `hero_theme` to `[workspace.dependencies]`), restore `hero_admin_lib` as a workspace member at `crates/hero_admin_lib` (parity with `main`). A heads-up on the expected timeline would help us schedule flipping the downstream `hero_admin_lib` pins to `development`.

zaelgohary referenced this issue from a commit

2026-06-17 14:52:15 +00:00

fix(workspace): restore hero_admin_lib as a member (parity with main)

zaelgohary changed title from ~~hero_admin_lib not a workspace member on development — unresolvable as a git dependency~~ to hero_admin_lib unresolvable as a git dep on development — parked as _old during in-flight hero_theme/asset refactor

2026-06-17 14:57:12 +00:00