Found while measuring #506 (workspace-package imports, #504).
typescript_extractor.file_path_to_module_fqn strips the last extension only, so a declaration file keeps .d:
packages/types/Calendar.d.ts -> packages.types.Calendar.d
An import names the module without it — import type { Calendar } from "@calcom/types/Calendar" — so after #506 maps @calcom/types to packages.types, the candidate packages.types.Calendar still matches no node. On cal.com 28 FILE nodes carry the suffix, and most of the 288 @calcom.* imports #506 leaves unresolved are this — @calcom.types.Calendar alone is 79.
Fix direction
Strip .d.ts / .d.tsx as one suffix before the single-extension loop. This renames existing node ids, so a graph built before the change and read after it holds ids nothing produces any more; an incremental ingest must rebuild, the same way #506 rebuilds when the package map changes.
Also worth deciding: when both Calendar.ts and Calendar.d.ts exist in one directory the two would then share an id.
Found while measuring #506 (workspace-package imports, #504).
typescript_extractor.file_path_to_module_fqnstrips the last extension only, so a declaration file keeps.d:An import names the module without it —
import type { Calendar } from "@calcom/types/Calendar"— so after #506 maps@calcom/typestopackages.types, the candidatepackages.types.Calendarstill matches no node. On cal.com 28 FILE nodes carry the suffix, and most of the 288@calcom.*imports #506 leaves unresolved are this —@calcom.types.Calendaralone is 79.Fix direction
Strip
.d.ts/.d.tsxas one suffix before the single-extension loop. This renames existing node ids, so a graph built before the change and read after it holds ids nothing produces any more; an incremental ingest must rebuild, the same way #506 rebuilds when the package map changes.Also worth deciding: when both
Calendar.tsandCalendar.d.tsexist in one directory the two would then share an id.