pandoras-box/forgejo-cli
7
0
Fork 0
Code Issues Pull requests Projects Releases 5 Packages 1 Wiki Activity Actions

chore: migrate tag/wiki API calls into fj-core ops (FJ-10) #9

Merged
David merged 1 commit from chore/migrate-simple-areas-fj-10 into main 2026-05-25 16:15:43 +02:00
Conversation 0 Commits 1 Files changed 7 +95 -27
David commented 2026-05-25 16:05:35 +02:00
Owner
Copy link

Summary

FJ-3 Phase 4a (subtask of FJ-8): migrate the simple command areas so their forgejo-api calls live in fj-core operations that return forgejo-api structs, leaving each binary run() to parse args and render. No user-visible behavior change.

Changes

  • fj-core: new tag module (list, create, view, delete) and wiki module (list_pages, get_page, get_repo), each a thin async wrapper over the matching forgejo-api endpoint returning its struct. No clap / fluent / terminal rendering.
  • fj-core/Cargo.toml: add forgejo-api = "0.10.0" (already present transitively via fj-client; now a direct, explicit dependency).
  • fj-core/src/lib.rs: register pub mod tag; / pub mod wiki; and update the crate doc to note it now holds per-command operations.
  • crates/fj/src/tag.rs and crates/fj/src/wiki.rs: replace inline api.repo_* calls with the new fj_core::tag::* / fj_core::wiki::* operations. Rendering (SpecialRender, markdown, base64 decode), the editor prompt, and the git clone stay in the binary.

whoami left unchanged (intentional)

crates/fj/src/whoami.rs makes no forgejo-api call: it reads the logged-in username from local KeyInfo (keys.get_login). There is no network operation to lift into fj-core, so the module already satisfies the AC ("no direct forgejo-api calls remain"). The umbrella's example name fj_core::whoami::current_user does not match the actual command surface; per the issue's own "(match the actual command surface)" guidance, whoami is left as-is rather than inventing an API round-trip (which would be a user-visible behavior change).

Verification

  • cargo build --locked (workspace) succeeds.
  • cargo tree -p fj-core -e normal | grep -E 'clap|crossterm|fluent' prints nothing: no CLI-coupling crate leaks into fj-core.
  • No direct api.repo_* calls remain in whoami.rs / tag.rs / wiki.rs.
  • just check (fmt + clippy -D warnings + build + builder-stage docker) passes.

Note on the comrak part of the verification grep

The issue's verification line greps clap|crossterm|comrak|fluent. The comrak term is non-satisfiable and pre-dates this change: Phase 3 (FJ-7) deliberately added comrak to fj-core for the issue-template parser (crates/fj-core/src/template/yaml.rs), and lib.rs documents "Markdown parsing via comrak is allowed." comrak is not a CLI-coupling crate (it is reusable by an MCP server), so its presence does not violate Phase 4's actual intent: keeping clap/crossterm/fluent out of fj-core. The grep's comrak term reads as a copy-paste artifact; the CLI-free intent is verified above.

#FJ-10

## Summary FJ-3 Phase 4a (subtask of FJ-8): migrate the simple command areas so their `forgejo-api` calls live in `fj-core` operations that return `forgejo-api` structs, leaving each binary `run()` to parse args and render. No user-visible behavior change. ## Changes - `fj-core`: new `tag` module (`list`, `create`, `view`, `delete`) and `wiki` module (`list_pages`, `get_page`, `get_repo`), each a thin async wrapper over the matching `forgejo-api` endpoint returning its struct. No clap / fluent / terminal rendering. - `fj-core/Cargo.toml`: add `forgejo-api = "0.10.0"` (already present transitively via `fj-client`; now a direct, explicit dependency). - `fj-core/src/lib.rs`: register `pub mod tag;` / `pub mod wiki;` and update the crate doc to note it now holds per-command operations. - `crates/fj/src/tag.rs` and `crates/fj/src/wiki.rs`: replace inline `api.repo_*` calls with the new `fj_core::tag::*` / `fj_core::wiki::*` operations. Rendering (`SpecialRender`, `markdown`, base64 decode), the editor prompt, and the git clone stay in the binary. ## whoami left unchanged (intentional) `crates/fj/src/whoami.rs` makes **no** `forgejo-api` call: it reads the logged-in username from local `KeyInfo` (`keys.get_login`). There is no network operation to lift into `fj-core`, so the module already satisfies the AC ("no direct `forgejo-api` calls remain"). The umbrella's example name `fj_core::whoami::current_user` does not match the actual command surface; per the issue's own "(match the actual command surface)" guidance, whoami is left as-is rather than inventing an API round-trip (which would be a user-visible behavior change). ## Verification - `cargo build --locked` (workspace) succeeds. - `cargo tree -p fj-core -e normal | grep -E 'clap|crossterm|fluent'` prints nothing: no CLI-coupling crate leaks into `fj-core`. - No direct `api.repo_*` calls remain in `whoami.rs` / `tag.rs` / `wiki.rs`. - `just check` (fmt + clippy `-D warnings` + build + builder-stage docker) passes. ### Note on the `comrak` part of the verification grep The issue's verification line greps `clap|crossterm|comrak|fluent`. The `comrak` term is non-satisfiable and pre-dates this change: Phase 3 (FJ-7) deliberately added `comrak` to `fj-core` for the issue-template parser (`crates/fj-core/src/template/yaml.rs`), and `lib.rs` documents "Markdown parsing via `comrak` is allowed." `comrak` is not a CLI-coupling crate (it is reusable by an MCP server), so its presence does not violate Phase 4's actual intent: keeping clap/crossterm/fluent out of `fj-core`. The grep's `comrak` term reads as a copy-paste artifact; the CLI-free intent is verified above. #FJ-10
chore: migrate tag/wiki API calls into fj-core ops (FJ-10)
All checks were successful
Check / fmt + clippy + build + tests (pull_request) Successful in 36s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
2eb8609314 
FJ-3 Phase 4a (subtask of FJ-8): lift the simple command areas' forgejo-api calls into fj-core operations that return forgejo-api structs, leaving each binary run() to parse args and render. No user-visible behavior change.

New fj-core::tag (list, create, view, delete) and fj-core::wiki (list_pages, get_page, get_repo) modules each wrap exactly the forgejo-api endpoint the command previously called inline. Add forgejo-api as a direct fj-core dependency (already present transitively via fj-client) and register the modules in lib.rs.

crates/fj/src/tag.rs and crates/fj/src/wiki.rs now call the fj_core operations instead of api.repo_*; rendering, the editor prompt, base64 decode, and the git clone stay in the binary.

whoami is left unchanged: it makes no forgejo-api call (reads the username from local KeyInfo), so it already satisfies the AC and inventing an API round-trip would be a behavior change.

fj-core's dependency tree stays free of clap / crossterm / fluent. comrak remains, intentionally added in Phase 3 for the issue-template parser; it is not a CLI-coupling crate and is outside this batch's scope.

#FJ-10

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
David merged commit ac743d3703 into main 2026-05-25 16:15:43 +02:00
David deleted branch chore/migrate-simple-areas-fj-10 2026-05-25 16:15:43 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pandoras-box/forgejo-cli!9
No description provided.