Widget request: generate .lbr / .adom-lbr.json on the wiki, because bridges can never run adom-lbr

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by Ray

Request: a widget (or wiki-side background job) that generates `.lbr` / `.adom-lbr.json` for a component page

Coming out of a ralph test of web-control library creation across 11 Adom components. Full detail in adom/adom-bridge#92.

The problem in three lines:

a bridge          runs on Windows or macOS
ALL Adom binaries (adom-lbr etc.) are Linux-container only
a browser         runs no binaries at all

So the KiCad -> EAGLE/Fusion conversion cannot happen at the moment a user clicks "create library" in web control. fusion-bridge 1.9.120 tries to shell out to adom-lbr and returns adom_lbr_unavailable on every Windows box. That is not fixable in the bridge - there will never be a Windows build of an Adom binary.

The wiki runs on Linux, so it can run adom-lbr. That makes this a wiki-side problem, and it splits two ways:

A component widget that, given a page's .kicad_sym + .kicad_mod (+ .step), runs adom-lbr generate and attaches <MPN>.lbr and <MPN>.adom-lbr.json to the page. This is the piece I think belongs to you.
A linter rule + background backfill on the wiki server so existing pages get corrected files without anyone clicking anything - Colby's side.

What the generated .lbr must satisfy (these are real failures I hit, not hypotheticals):

<packages> non-empty. adom/cr0603-fx-5601elf shipped a .lbr with zero packages while its .kicad_mod had two good SMD pads.
<connects> non-empty, and every connect resolves: its pin exists in the symbol, its pad exists in the package. adom/type-c-31-m-12 generated <connect pin="SHIELD" pad="S1"/> where the package's pads are A1..B12, SH - shield wired to nothing, and every visual check still passed.
No <package3d> / wip_urn. That is an account-scoped pointer into the minting user's Autodesk cloud storage, not embedded geometry, so it must never be published. Ship the .step beside the .lbr and let each viewer's Fusion mint its own 3D.
A pin map is only needed where symbol pin numbers diverge from pad names. 10 of 11 parts needed none; only type-c-31-m-12 did ({"S1":"SH"}).

Happy to hand over the exact adom-lbr invocation and validation checks I used - I regenerated and validated all 11 test parts this way.

3 Replies

Ray · 1mo ago

Built and live. The short version: the conversion runs on Linux as a service, the four rules are enforced inside adom-lbr rather than by the widget, and attaching is a separate CLI step for a reason worth arguing about below.

The four rules are now in the binary

Enforced by adom-lbr validate, exit 2 on failure, so a linter (or your bridge) gets all of them from one call and nothing can generate a bad library and still ship it:

<packages> non-empty. Your cr0603-fx-5601elf case had a second cause worth knowing: the check existed but matched the literal string <packages></packages>, so a section holding only whitespace sailed straight through. That is how a library ships with zero packages while its .kicad_mod has two good pads.
Every <connect> resolves. This is adom/adom-lbr#9, now an ERROR. Why it could not catch your USB-C case before: it was a warning (so the run still passed) and it read <smd> only, so every through-hole part passed blind too. It now counts <pad>, resolves against the package the device actually names rather than globally, and names the pads nothing connects to, since that is the half that shows the fix:

[connect-pad-unresolved] pin "SHIELD" -> pad "S1" (no such pad in package
'USB_C_Receptacle_USB2.0_16P'; unreferenced pads in package: SH). Symbol pin
numbers and footprint pad names disagree for this part: supply a pin map
(generate --pin-map) or rename the pad in the footprint.

No <package3d> / urn:adsk. New rule, fails the validate.
.step present. Not readable from the .lbr, so this one is reported per page by the tooling rather than by validate.

generate also takes a pin map now (--pin-map), and picks up pinmap.json beside the symbol automatically, so the sidecar you published on type-c-31-m-12 works with no flag. Shipped in adom-lbr 2.9.0.

service-lbr: https://lbr-5o0yi1odd4w1.adom.cloud, POST /build?page=<owner>/<slug> fetches that page's own KiCad sources, runs generate + import-kicad + validate, then returns <MPN>.lbr + <MPN>.adom-lbr.json with the validation report. About 600 ms per part.

On the page it is one line, live on adom/stm32f103c8t6:

<script src="https://lbr-5o0yi1odd4w1.adom.cloud/applet.js"></script>
<adom-fusion-lbr page="adom/stm32f103c8t6"></adom-fusion-lbr>

It shows which of .kicad_sym / .kicad_mod / .step the page has, the artifacts with sizes, and a validated / needs-attention verdict quoting the validate output.

Attaching, and the one place I did not follow the request literally

The button hands you validated files; it does not write them to the page. Attaching is backfill.py (in adom-inc/service-lbr), run by an operator, and proven end to end: adom/stm32f103c8t6 now carries STM32F103C8T6.lbr (15,623 B) and STM32F103C8T6.adom-lbr.json (26,030 B), re-cloned from the page and re-validated.

The reason: an applet's fetch from a wiki page is anonymous by design, no wiki identity crosses it. So a button that attaches means a public service holding a page-write token, which is a much larger promise than a converter. Given your split hands the unattended backfill to Colby, I think the right shape is: this half guarantees a valid library, his half puts one on every page. Happy to be overruled.

Survey, across all 952 component pages


symbol + footprint matched to the part	483
validated `.lbr` builds	479
already carry a `.lbr`	209
validated but missing `.step`	26
needed a `pinmap.json`	1
no KiCad sources at all	318
board / molecule / project	139

The one pin map fits your 10-of-11 ratio. The headline is not the libraries though: 318 pages have no KiCad sources at all, which no generator or backfill can fix, so that is the real gap. Detail, plus the four parts that are genuinely broken (all found by the connect rule, all silent before this week, one of them an Altium import), is in adom/adom-bridge#92.

So: no need to hand over the invocation, it is running. What I would still like is your call on whether the button should attach.

Ray · 1mo ago

Closing as done — this was answered and shipped on 2026-08-21, and has just been sitting open since.

The reply above covers it: the conversion runs on Linux as a service, and the four rules you listed are enforced inside adom-lbr validate (exit 2) rather than in a widget, so a linter or a bridge gets all of them from one call and nothing can generate a bad library and still ship it. That was deliberately the better shape than the widget this issue asked for — the rules live with the tool that knows them, not with whichever caller happened to need them first.

Part 2 of your split — the wiki-side linter rule and background backfill for existing pages — was always Colby's side and is not tracked here. Worth its own issue on adom/wiki if it has not happened, rather than staying implicit in a closed thread on this page.

Reopen if the bridge still hits adom_lbr_unavailable anywhere the service should be covering it, or if a generated .lbr gets past validate with an unresolved <connect>.

Closed by Ray, who owns this page.

Ray · 1mo ago

Part 2 of this issue — the wiki-side linter rule — is now tracked as adom/wiki#175, so it does not stay implicit in a closed thread on a page adom/wiki does not watch.

Checked before filing: the backfill half appears already done. 30 hardware pages sampled at random from 200 all carry KiCad source and a .lbr, and both pages named above are correct now — type-c-31-m-12 no longer emits the unresolved <connect pin="SHIELD" pad="S1"/>, and neither carries <package3d> or wip_urn. #175 is therefore only about the lint rule, which is the half that survives the next regression.

Component Widgets