CodeVetter · Repo Unpack · Risk map
remeda/remeda
The most consequential source boundaries are dynamic utility dispatch, declaration rewriting, browser-loaded dependencies, HTML insertion, and agent hooks that execute commands or write files. These observations do not establish vulnerabilities. Two plausible behavior or maintenance risks are explicitly identified as hypotheses requiring verification. Browser interactions have less executable evidence than the library because the docs package documents no tests.
- purry explicitly describes itself as dynamically typed and depends on fn.length for dispatch; changing implementation arity can therefore alter both calling styles across utilities that delegate to it.
- randomString uses Math.random to select alphanumeric characters and explicitly warns that it is not cryptographically secure; using it for authentication tokens would violate its documented capability.
- Hypothesis: the website console sandbox can differ from the locally built documentation API because every base page loads sandbox.js, which imports an unversioned remeda module from esm.sh rather than the workspace artifact. (inferred)
- Hypothesis: system-preference changes mishandle theme overrides because initTheme's change listener enables dark mode when a stored choice exists, whereas initial selection follows the media query only when storage is absent; no browser reproduction was performed. (inferred)
- Declaration postprocessing relies on regex extraction and an export-statement insertion pattern; it throws when polyfills or an insertion point are missing and also rewrites Unicode separators for older TypeScript compatibility.
- Markdown rendering crosses an explicit set:html boundary protected by marked-to-DOMPurify sanitization; the docs package documents no tests, so this inspection does not establish sanitization regression coverage.
- Agent stop hooks execute commands through spawnSync with inherited process environment and snapshot dirty files beneath an OS temporary directory; CLAUDE_PROJECT_DIR supplies package-root resolution, making this tooling a separate execution and filesystem boundary.
- The post-edit formatter reads and rewrites tool_input.file_path after existence and parser checks; this handler contains no explicit repository-root containment check, so its allowed write boundary depends on the host tool and environment.