_read_tsconfig_aliases() silently fails on tsconfig.json with comments — every JS/TS project hits this

[jippi]

Follow-up to #691 (and the v0.7.1 fix). The extends chain is now followed correctly, but the underlying parser still uses json.loads, which raises on // line comments and trailing commas — i.e. on the de-facto format every TypeScript tool ships and every framework starter generates. The exception is swallowed by the bare except Exception: return {} at extract.py:62-63, so _load_tsconfig_aliases() returns {} and every aliased import falls into the bare-package branch, exactly as it did pre-#691.

Repro (real project — 1,870-file SvelteKit app)

tsconfig.json — the only thing that matters is one trailing-line comment, generated as-is by pnpm create svelte / npm create vite / nx / NestJS / T3 / Astro:

{
  "extends": "./.svelte-kit/tsconfig.json",
  "compilerOptions": {
    "skipLibCheck": true, // only way to make svelte-check not include node_modules
    "strict": true
  }
}

.svelte-kit/tsconfig.json (auto-generated by svelte-kit sync, has the actual paths):

{
  "compilerOptions": {
    "paths": {
      "$lib": ["../src/lib"],
      "$lib/*": ["../src/lib/*"],
      "$partials": ["../src/partials"],
      "$partials/*": ["../src/partials/*"]
    }
  }
}

Observed:

>>> from graphify.extract import _load_tsconfig_aliases
>>> _load_tsconfig_aliases(Path('src/lib/server'))
{}

The silent except at extract.py:60-63 masks json.JSONDecodeError: Expecting property name enclosed in double quotes: line 22 column 25.

Expected (what you get if json.loads is monkey-patched to strip // comments first):

$lib       -> /…/website/.svelte-kit/../src/lib
$partials  -> /…/website/.svelte-kit/../src/partials
$app/types -> /…/website/.svelte-kit/types/index.d.ts

So the extends-following logic from #691 does work — it's just unreachable in practice because the parent file fails to parse.

How aliases are used in this codebase

These are exactly the imports the resolver needs to handle. All standard SvelteKit shapes:

// src/hooks.server.ts (TS, top-level alias usage)
import { connect_to_db, disconnect_from_db } from '$lib/server/database'
import { MBSQLError } from '$lib/server/database/series.mbsql'
import { auth_check } from '$lib/server/middleware/auth-check'

// src/app.d.ts (type-only imports — also alias-resolved)
import type { ListConfigurationSection } from '$lib/types/series-list-config'
import type { ContentRating } from '$lib/types/series-ui-options'

<!-- src/lib/components/series/similar/similar-series-section.svelte (Svelte <script>) -->
import RecommendationCarousel from '$lib/components/recommendations/recommendation-carousel.svelte'
import ImageV2 from '$partials/Series/ImageV2.svelte'
import SimpleTooltip from '$partials/SimpleTooltip.svelte'

Repo-wide totals: 4,246 $lib/... imports, 478 $partials/... imports across .ts / .svelte files. Currently every one of them falls through to the bare-package branch.

Impact

For our 1,870-file SvelteKit corpus on graphifyy 0.7.2:

• imports_from edges from .svelte files: 18 (essentially unchanged from v0.7.0's 18)
• .svelte orphan files: 314 (unchanged from v0.7.0's 314)
• Total edges: 11,179 (byte-identical to v0.7.0)

The v0.7.1/0.7.2 upgrade produced zero net new edges in our graph because the JSONC failure short-circuits everything before the new extends logic runs.

Note: the bare except Exception: return {} at extract.py:60-63 made this surprisingly hard to diagnose — there's no signal anywhere that alias loading failed.

[safishamsi]

Fixed in the next release.

_read_tsconfig_aliases() now handles JSONC (the format every TypeScript tool generates):

• // line comments
• /* */ block comments
• Trailing commas before } and ]

A _strip_jsonc() helper uses a single regex that respects string literals (so // inside a URL string is preserved). Parse order: try plain json.loads first (fast path), fall back to the stripped parse, and if that also fails — warn to stderr with file path + error location instead of silently returning {}.

The extends-following logic from #691 was always correct; it was just unreachable because the parent tsconfig failed to parse. Both work together now.