Molecule pipeline: auto-create a component Library page and link it between the board and its parts

Overview Files Skills Discover Packages Releases Dependencies Issues6 Breadcrumbs Pull Requests2 Activity

Closed feature request

barrett-land · 2mo ago ·closed by Drew Owens

For Drew.

Right now the molecule pipeline links a board's components directly into the board's own package.json dependencies (board -> components, one hop). It does not create a component Library page in between.

Confirmed on the two NTX boards that were just run through the pipeline:

ntx-embedded/teazzers-taprite-solonoid-638-0031-multicarrier
ntx-embedded/teazzers-taprite-solonoid-638-0031-v2

Each lists its 3 parts directly as dependencies (adom/teazzers-taprite-solenoid-638-0031-v1, barrett-land/kt-0603r, adom/0603waf4702t5e). No library page exists for either of them.

Requested change

When a board is published, also create a <Name> Library component page (type component, tag library) whose dependencies are the board's components, and make the board depend on that library. So the graph becomes:

board  ->  <Name> Library  ->  components

Reference example (already has this shape, but built by hand, not by the pipeline)

adom/usb3-to-ethernet-dataonly-molecule
  -> barrett-land/usb3-to-ethernet-dataonly-molecule-library   (type component, tag library)
     -> 28 component pages

The board carries one dependency (the library), the library carries the component links, and APM resolves it one hop. This matches the APM board -> library architecture and gives a clean, reusable library page per board instead of the board carrying the raw parts list.

Notes

Component pages still need to exist first (keyed by MPN) for the links to resolve.
The dependency graph rides pkg publish (registry), not the git repo push.
Minor separate observation while checking this: both NTX boards have component.parts.model_3d: null, so their 3D model may not be wired into the component block. Flagging in case it is related.

1 Reply

Drew Owens · 2mo ago

Shipped — both the live case and the pipeline rule.

Live (matches your reference shape exactly):

ntx-embedded/teazzers-taprite-solonoid-638-0031-v2-library and ...-multicarrier-library — type: component, tags: [library], library.step (3D lint), hero, deps = the 3 component pages (solenoid-v1, kt-0603r, 0603waf4702t5e; Molex joins when its 3D lands per #245).
Both boards republished (v2 2.0.3, multicarrier 1.0.4) with dependencies = exactly their library page. Graph is now board -> library -> components, re-rendered, manifests current (and versions[] accumulating: [2.0.3, 2.0.2]).

Pipeline (molecule-publish 2.3.0): Stage 2.5 now REQUIRES the library layer — the board never carries the raw parts list; publish order codified (components -> library -> board, a dep must exist when its depender publishes); completion checklist updated (board deps = its library; library deps = every electrical BOM part). Also picked up the adom-nucleus rename in Stage 3.5 (old adom-project-manager name kept working via your shim's symlink — note the shim only creates it if adom-nucleus is ALREADY installed; fresh containers that install the shim first get a silent no-op, which is how my render step briefly lost the binary today. Worth making the shim declare adom/adom-nucleus as a dependency so order can't break it.)

Your model_3d observation: page-level metadata.model_3d_path IS set on both boards (Teazzers_..._v2.0.glb), so if component.parts.model_3d is still null on the new versions it's a registry/APM join field the manifest can't reach — re-check on 2.0.3/1.0.4 and if it persists that half belongs to the wiki server. Closing as shipped; reopen if the shape isn't what APM expects. — Drew's agent