CodeVetter · Repo Unpack · Risk map
solidjs/solid
The strongest source-observed boundaries are configured code execution and output paths in static generation, external execution in optional integration tests, and shared runtime state. Package-condition mistakes and duplicated client/server behavior can affect broad portions of the public API. These are source observations or labeled hypotheses, not confirmed vulnerabilities or runtime failures.
- Static generation executes a caller-selected entry module and writes a caller-selected output path without repository-root confinement in the inspected runner; execFile uses a fixed Node executable and an argument array rather than shell interpolation.
- writeToDisk discards mkdir/writeFile callback errors and exits with status zero from the write callback; filesystem failures are not explicitly propagated by this source.
- The optional downloaded-test suite crosses network and shell boundaries, executes a downloaded project's tests, creates tarballs, and contains recursive cleanup operations; it is unsuitable for this read-only investigation.
- Conditional exports are behavior-sensitive: Node core signals do not build the client dependency graph, and browser renderToString/renderToStream mocks only log unsupported-use errors.
- Computations and cleanups created without an Owner receive development warnings that they will not be disposed/run; root ownership and disposal are explicit lifecycle responsibilities.
- Client tests share runtime state because isolate:false is enabled; the transition regression explicitly resets scheduling after another suite's enableScheduling call, documenting cross-test scheduler coupling.
- Unsafe-key handling must remain consistent across client store updates, server store updates, and reconcile: each has guards, and tests deliberately preserve constructor/prototype as final keys.
- Server rendering duplicates escape and resolveSSRNode logic, with an explicit source comment calling out duplication from solid-js/web; the external server implementation was not available as tracked source here.
- Server SuspenseList contains a TODO for revealOrder/tail and simply returns children after context handling, whereas the client implements reveal-order and tail policies.
- SSR example documentation has drift: it advertises localhost:8080 and Lerna commands, while inspected Express examples use port 3000 and manifests supply direct Rollup/Node scripts.
- Hypothesis: an application exposing store range setters to unchecked input could hang on a zero or backward by value, because the inspected client/server loops increment i by by without validating progress. (inferred)
- Hypothesis: renderer/compiler dependency changes can have a broad blast radius because DOM, SSR, tagged-template, hyperscript, and universal implementation adapters delegate to external expression packages; local adapters alone cannot establish their security properties. (inferred)