Debug your code, not the Runtime
As a developer you'll often need to inspect call stacks to debug your code, not the Runtime.
Tools like Error.stack() provide more information than needed, cluttering your call stack with
Runtime internals (i.e. node:internals) which you don't care about; you're only concerned with
your code.
npm i cstack # includes type definitions for TypeScript support
import cstack from "cstack";
function firstCall() {
console.debug("1");
secondCall();
}
function secondCall() {
console.debug("2");
thirdCall();
}
function thirdCall() {
console.debug("3");
console.log(cstack.getStack()); // -> StackFrame[]
console.log(cstack.getParent("secondCall")); // -> "firstCall"
console.log(cstack.getTrace(true)); // -> reversed stack trace (chronological)
}
firstCall();
MIT License
FAQs
Debug your code, not the Runtime
We found that cstack demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
A supply chain attack on Axios introduced a malicious dependency, plain-crypto-js@4.2.1, published minutes earlier and absent from the project’s GitHub releases.
Research
Malicious versions of the Telnyx Python SDK on PyPI delivered credential-stealing malware via a multi-stage supply chain attack.
Security News
TeamPCP is partnering with ransomware group Vect to turn open source supply chain attacks on tools like Trivy and LiteLLM into large-scale ransomware operations.