Skip to content

Conversation

@sindresorhus
Copy link
Owner

@sindresorhus sindresorhus commented Sep 19, 2025

Fixes #34

It's opt-in since it does come with a tiny performance overhead.

From a lot of research, this is the only way I managed to preserve the stack trace.

Comment on lines +14 to +26
// Node.js and Chrome: '\n at '
if (capturedStack.includes('\n at ')) {
frameSeparator = '\n at ';
} else if (capturedStack.includes('@')) {
// Firefox: '\n' (simpler format)
frameSeparator = '\n';
} else if (capturedStack.includes('\n\t')) {
// Safari/JSC: varies, try common patterns
frameSeparator = '\n\t';
} else {
// Fallback to generic newline separation
frameSeparator = '\n';
}
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't extensively tested this yet. Will do if we decide to do accept this PR.

@sindresorhus
Copy link
Owner Author

@Richienb Thoughts?

@Richienb
Copy link
Contributor

I think it would be ok to enable by default because the happy path won't receive a performance hit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Stack trace is lost from the point the code uses p-map

3 participants