You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The downstream consumer afm (P4suta/afm) mirrors this renderer's
CSS-class contract by hand. In crates/afm-markdown-test-support/src/lib.rs
(lib.rs:62-86) it keeps an AFM_CLASSES: &[&str] constant and documents why it is maintained manually:
Sibling aozora-render embeds the aozora-* class names as string
literals inside writer.write_str(...) calls — there is no exported pub const we could import. Build-time fetch of the sibling source is
technically possible but heavyweight (depends on cargo metadata + a
regex scan).
So whenever aozora-render adds a class, afm's tests/css_class_contract.rs fails and a human has to append the new
name to AFM_CLASSES (and to the two mdbook themes). Drift is caught,
but the fix is manual and the class list is duplicated downstream.
What to do
Expose the set of CSS class names that aozora-render can emit as part
of its public API. A few shapes that would work:
/// Every CSS class the HTML renderer can emit.pubconstAOZORA_CLASSES:&[&str] = &["aozora-bouten",/* … */];
or named consts the renderer itself uses at the write_str sites (so the
authoritative list and the emit sites cannot drift), or a pub fn classes() -> &'static [&'static str].
Why it helps
afm imports the constant directly and deletes its hand-maintained
mirror + manual-append step entirely.
Drift detection moves upstream — to where the classes are defined —
instead of surfacing only as a failing downstream integration test.
It unblocks afm's automation sketch (a build.rs/future-ADR that was
going to fetch this source tree and regex-extract class="aozora-…"
literals). With a pub const there is nothing to scrape.
References
afm crates/afm-markdown-test-support/src/lib.rs:62-86 (the manual
mirror + the rationale quoted above)
afm crates/afm-markdown/tests/css_class_contract.rs (the drift gate)
Background
The downstream consumer afm (
P4suta/afm) mirrors this renderer'sCSS-class contract by hand. In
crates/afm-markdown-test-support/src/lib.rs(lib.rs:62-86) it keeps an
AFM_CLASSES: &[&str]constant and documentswhy it is maintained manually:
So whenever
aozora-renderadds a class, afm'stests/css_class_contract.rsfails and a human has to append the newname to
AFM_CLASSES(and to the two mdbook themes). Drift is caught,but the fix is manual and the class list is duplicated downstream.
What to do
Expose the set of CSS class names that
aozora-rendercan emit as partof its public API. A few shapes that would work:
or named consts the renderer itself uses at the
write_strsites (so theauthoritative list and the emit sites cannot drift), or a
pub fn classes() -> &'static [&'static str].Why it helps
mirror + manual-append step entirely.
instead of surfacing only as a failing downstream integration test.
build.rs/future-ADR that wasgoing to fetch this source tree and regex-extract
class="aozora-…"literals). With a
pub constthere is nothing to scrape.References
crates/afm-markdown-test-support/src/lib.rs:62-86(the manualmirror + the rationale quoted above)
crates/afm-markdown/tests/css_class_contract.rs(the drift gate)feat(test): automate AFM_CLASSES discovery)