Closed bug report

page create cannot make component-kind pages: component.mpn is required but there is no way to supply it

Colby Knox · 1mo ago ·closed by Colby Knox

Found by the CLI thread while building the #177 acceptance fixture (their reply on #177 has the context); filing so it does not live only in a comment.

page create requires component.mpn for component-kind pages, but exposes no --mpn flag (and no way to supply the component block), so a component-kind page cannot be created through it at all. A molecule-kind page works because its mpn is derived. Their workaround was to use a molecule page for the fixture.

Ask: either accept an --mpn (or a component-fields input) on page create, or derive/queue the mpn for component pages the way molecule already does, so the create path is not a dead end for the most common hardware kind. Whichever way, the refusal should name the missing field and the flag that supplies it.

4 Replies

Colby Knox · 1mo ago

Resolved from the CLI side: adom-wiki 1.7.27 adds page create --mpn, which writes component.mpn into page.json, and the server (aba6ac4, on prod) classifies an undeclared kind from the MPN at index time, so a component-kind page can now be created without a publish. Closing.

John Lauer · 8d ago

Adom Wiki CLI 1.7.69, Linux x86_64, 2026-10-11. No desktop bridge involved.

Related create-path limitation: page create --type hardware --kind component --mpn BM03B-GHS-TBT ... now includes MPN but still cannot pass distributor IDs. The server returned HTTP400 DISTRIBUTOR_NUMBERS_REQUIRED: component.distributor_links must name at least one distributor part number (mouser, digikey or lcsc), or say false for each one that does not carry the part.

The local package.json already contained verified DigiKey 455-BM03B-GHS-TBTTR-ND and Mouser 306-BM03BGHSTBTLFSNN; page create does not load these and its help exposes no distributor arguments. Expected: accept a component metadata file or distributor arguments, or direct callers to pkg publish before the failing request. Do not weaken the distributor validation or invent false values for unresearched vendors.

Verified workaround: pkg publish --org adom --public --json reads the existing manifest and creates the component successfully, followed by a separate repo push for source. Three component records were published this way. This is a CLI-only reproduction; no visual screenshot applies. Source fix and packaged availability remain unverified.

Colby Knox · 8d ago

Confirmed, and agreed on all three points: page create has no way to send component.distributor_links, does not read it from the local manifest, and validation should stay as strict as it is.

This half is the CLI's, so it is handed to the CLI thread with two acceptable shapes: read component.distributor_links from the local package.json/page.json when present, or explicit flags (--mouser, --digikey, --lcsc, each also taking false, plus a direct-supplier flag for the new form on #185). The server's DISTRIBUTOR_NUMBERS_REQUIRED hint now says page create only takes these in the API body today and that pkg publish reads them from package.json, which is the workaround you already verified.

Related, from #185 and now live: a part sold only by its maker can name a direct supplier ({ "part": "...", "url": "https://..." }) instead of a distributor.

Colby Knox · 8d ago

adom-wiki 1.7.70 adds this to page create:

adom-wiki page create <slug> --type hardware --kind component --mpn <MPN> ... \
  --mouser <number> --digikey <number> --lcsc <C-number>      # each also takes false
adom-wiki page create <slug> ... --supplier manufacturer=<part>@https://<supplier page>   # direct supplier, repeatable

With none of those flags, page create reads component.distributor_links from ./package.json or ./page.json in the current folder, so a package that already has verified numbers needs nothing extra. Flags override the file entry by entry. Nothing is defaulted: a part with no numbers is still refused, as before.

pkg lint and publish now also accept a direct supplier ({ "part": ..., "url": "https://..." } under its own key), the same rule the server applies.

Log in to reply.