Troubleshooting

Module resolution problems — almost always directory or import-path issues.

Example first

“Cannot find module '@typecad/pcb'”

• Work happens in the hw/ directory — check you're there
• hw/package.json must list @typecad/pcb as a dependency
• Run npm install in hw/

“Module has no exported member …”

Importing a component from a subpath instead of the package root:

// ❌ wrong — components don't live on subpaths
import { Connector } from '@typecad/pcb/passives';

// ✅ every component ships from the package root
// (the real subpaths — /routing, /diff, /docgen, ... — are tooling APIs)
import { Connector } from '@typecad/pcb';

The two connection shapes people reach for first — neither exists.

Example first

// ❌ wrong
pin1.connect(pin2);

// ✅ connections live on the PCB
typecad.net(pin1, pin2);

// ❌ wrong — generated components don't take pin names as strings
esp32.pin('VDD')

// ✅ named pins are properties; numbers always work
esp32.VDD        // or esp32.pin(8) if VDD is pin 8

Generated components and their options.

Example first

“Cannot find name 'ComponentName'”

• Create the component with typecad-pcb add component
• Check the import statement matches the generated file name
• Generated files live in hw/src/

Option names

// ❌ wrong
new Connector({ pins: 3 })

// ✅ the option is number
new Connector({ number: 3 })

Check the generated file's header comment — every component documents its options there.

Two checklists: one for TypeScript failures, one for the generated KiCAD output.

Example first

TypeScript compilation

• Check all imports are correct
• Every component reaches the output through typecad.create(...)
• Pin connections use typecad.net(...)

KiCAD generation

• All components have valid symbol and footprint paths
• Nets have at least two pins — typecad-pcb query unconnected finds the lonely ones
• Reference designators are unique