Skip to content

fpc throws a raw parse error when called by its bare name, unlike every other pin-count footprint #786

Description

@zkasuran

What happens

Calling the fpc footprint by its bare name throws a raw Zod parse error before any geometry is built:

import { fp } from "@tscircuit/footprinter"

fp.string("fpc").circuitJson()
ZodError: [
  {
    "code": "invalid_type",
    "expected": "number",
    "received": "nan",
    "path": ["num_pins"],
    "message": "Expected number, received nan"
  }
]

Why it happens

In src/fn/fpc.ts the pin count has no default:

num_pins: z.coerce.number().int().min(2),

When no count is given the proxy sets num_pins to undefined. z.coerce.number() turns that into NaN, so the parse fails.

Why it is a bug

Every other footprint that takes a pin count defaults it, so it renders from a bare name:

  • bga defaults to 64, quad to 64
  • ssop to 8, dip to 6, lga to 14
  • son to 8, sot223 to 4
  • the two-pin parts (sma, smc, sod123 and friends) default to 2

fpc is the only pin-count footprint that throws instead of rendering. This is the same gap #782 describes for vson8.

The fpc defaults are already tuned around a 12-pin part. The existing fpc12 test reproduces FPC-05F-12PH20 from nothing but the schema defaults (p0.5mm pw0.3mm pl1.25mm mpw2mm mpl2.5mm, with mpx and mpy computed to 8.88 and 2.575). A bare fpc therefore has an obvious intended result: the 12-pin FPC-05F-12PH20 layout.

Expected

fp.string("fpc").circuitJson() renders the 12-pin FPC-05F-12PH20 footprint (14 pads) instead of throwing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions