Preact example

[mindplay-dk]

Hi,

Very interesting project! I am particularly intrigued with the idea of deterministic processing. 😊

I was looking at the Preact demo:

https://demo.codenib.ai/preactjs__preact

And two things occurred to me:

1. The dependency map on that page is very meagre - it seems only .d.ts files were processed. Is that by design? It would seem to make sense if only the published artifacts were processed - but your tool processed the entire source repository. I was expecting at least a graph of modules, or maybe even the coupling between the individual units in the modules? Is this a graph or everything the tool discovered?

2. For a repository like Preact specifically, which has extremely high "signal to noise" ratio (the code is extremely optimized and condensed) it occurs to me, all of the text in that catalog is probably more tokens than the entire source code of Preact - do you have any benchmarks or evidence to support the tokens savings claims specifically for a repository like this one?

Very cool project either way! I expect this will work quite well for low "signal to noise" projects, such as business applications with all their boilerplate. I was just wondering how well it's expected to perform on extremely condensed code, such as Preact. 😊

Thanks!

[fishmingyu]

Thanks for trying out the demo and for the detailed questions!

Triage: this reads as a usage/design question rather than a bug report or feature request, so no repro/version info is needed — labeling as question + scope/graph (dependency-graph completeness in the demo) and scope/eval (token-savings benchmark evidence). Priority set to P3 (nice-to-have, no workflow blocked).

@siriuxyu could you weigh in on (1) whether the sparse Preact dependency map is expected/by-design (e.g. only .d.ts/SCIP-resolved edges surfaced) vs. a gap in graph construction for highly-condensed source, and (2) whether we have benchmark numbers for token savings on low signal-to-noise repos like Preact?

---

Generated by Claude Code

[fishmingyu]

Hi @mindplay-dk , thank you so much for your authentic feedback! It's basically a research demo now, since we lack a product manager and real effort on product design. We will continue to provide better products for users in the future.

[fishmingyu]

@mindplay-dk you were right, and it turned out to be a real bug — thanks for the
precise report. #396 has the fix.

On (1) — the sparse dependency map. Not by design, and not a parsing gap
either: the whole repo was processed, and the JS graph is there. Asking the
demo API for a symbol directly returns real edges:

$ curl '.../codemap?symbol=diffChildren&depth=1'
root: src/diff/children.js:diffChildren()
  → src/create-element.js:createVNode()
  → src/diff/index.js:diff() / applyRef()
  → src/component.js:getDomSibling()

What you saw was the default view. With no symbol selected, the codemap seeded
on whichever symbol had the highest reference out-degree — a graph-theoretic
answer to a product question. src/dom.d.ts declares 127 interfaces over ~1400
property lines, and Signalish alone is referenced 496 times, against ~5k lines
of very dense hand-written JS. So SVGAttributes won by a mile, and a depth-2
walk from there never left the file: 36 of 40 nodes were HTML attribute typedefs,
with no semantically interesting edge among them.

Your instinct that Preact's signal-to-noise ratio was the trigger is right,
though not quite for the reason you guessed — it is the ratio of declared types
to executable code, not the density of the code itself. It is also not a
TypeScript problem. pydata/xarray in the same demo failed identically, seeding
on xarray/core/_typed_ops.py, which is emitted by xarray/util/generate_ops.py.
Two of the three repos I sampled were hijacked by declaration mass.

The fix ranks declaration stubs, build artifacts, generated files and tests below
hand-written source when picking the seed, and holds them out of the PageRank
restart set so a wall of typedefs referencing each other can no longer manufacture
its own importance. They are demoted, not deleted — a hand-written
src/internal.d.ts type that the renderer genuinely leans on keeps its rank, and
a repo that really is all declarations still gets a map. It is a read-time change,
so it lands on the demo at the next deploy without re-indexing.

On the module-level graph you expected. That one is a genuine gap, and a
bigger one than the seeding bug. codemap?symbol=src/index.js returns 1 node and
0 edges today, because the map only walks symbol-to-symbol reference edges and
src/index.js is a pure re-export barrel. import is defined as an edge type in
codenib/types.py but no decoder emits it — every graph we build is
reference + contain only. So there is currently no module-level view to
render, at any zoom. Tracking that separately.

On (2) — token savings on condensed code. No, we don't have numbers for a
repo like Preact specifically, and I'd rather say that than wave at an average.
Your framing is the sharp one: for a codebase small and dense enough that the
whole thing fits in context, retrieval overhead can exceed what it saves, and the
crossover point is a function of repo size and redundancy, not a constant. That is
the benchmark worth running, and we haven't run it. Preact is a good adversarial
case for exactly that reason.

Thanks again — this was a much more useful report than most bug reports.