Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

alternative stack trace approach #2119

Merged
merged 16 commits into from
Nov 12, 2022
Merged

alternative stack trace approach #2119

merged 16 commits into from
Nov 12, 2022

Conversation

davidjgoss
Copy link
Contributor

@davidjgoss davidjgoss commented Aug 22, 2022

🤔 What's changed?

Stop using stack-chain to temporarily modify stack trace behaviour in a V8-specific manner, for when we filter stack traces (i.e. with --backtrace option). Pivot to parsing the stack with error-stack-parser without modifying how it's created, and filtering from that.

Also add some documentation around source maps.

⚡️ What's your motivation?

This started with me digging around to try and understand this aspect of our codebase better, but I wanted to run with this approach and see if it's viable.

Hooking into V8's stack trace API in the way that stack-chain does in order to filter the stack trace for display seems like a bit of a sledgehammer to me. It also doesn't fail gracefully - in a non-V8 environment it will throw and exit, and this happens as soon as you import stack-chain, not just when you call methods on it. This is the only reason we can't do a live demo with StackBlitz, for example, and also seems likely to be a hindrance as we look to become less Node.js-centric and work with e.g. Deno and Bun.

On the flipside, parsing the stack trace is inevitably less scientific and more error-prone, and there will be some edge cases that go weird. For example stacktracejs/error-stack-parser#62 which contributed to us to moving away from the stacktrace.js libraries before (I've raised a fix for this now). I think it would be worthwhile though.

This change has also fixed an issue I was seeing when creating an example TypeScript+ESM project, where source references and stack traces were coming out with wrong locations that didn't correspond to either the source or transpiled JavaScript.

This area isn't very well covered by tests, so I'm going to try and flesh some out before I mark this as ready.

🏷️ What kind of change is this?

  • 🏦 Refactoring/debt/DX (improvement to code design, tooling, documentation etc. without changing behaviour)
  • 🐛 Bug fix (non-breaking change which fixes a defect)

📋 Checklist:

  • I agree to respect and uphold the Cucumber Community Code of Conduct
  • I've changed the behaviour of the code
    • I have added/updated tests to cover my changes.
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.
  • Users should know about my change
    • I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

This text was originally generated from a template, then edited by hand. You can modify the template here.

@coveralls
Copy link

coveralls commented Aug 22, 2022

Coverage Status

Coverage decreased (-0.004%) to 98.252% when pulling ef19e77 on feat/nodejs-source-maps into e88c691 on main.

}
return format(error, {
colorFns: {
errorStack: (stack: string) =>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm kind of abusing the assertion-error-formatter API here, which doesn't feel great. It could maybe do with a formatErrorStack option where you can provide a function that rewrites the stack as desired?

@davidjgoss davidjgoss changed the title experiment with alternate stack trace approach alternative stack trace approach Aug 23, 2022
@davidjgoss davidjgoss marked this pull request as ready for review September 14, 2022 17:11
@@ -309,7 +308,7 @@
"prepublishOnly": "rm -rf lib && npm run build-local",
"pretest-coverage": "npm run build-local",
"pretypes-test": "npm run build-local",
"test-coverage": "nyc --silent mocha 'src/**/*_spec.ts' 'compatibility/**/*_spec.ts' && nyc --silent --no-clean node bin/cucumber.js && nyc report --reporter=lcov",
"test-coverage": "nyc --silent mocha 'src/**/*_spec.ts' 'compatibility/**/*_spec.ts' && nyc --silent --no-clean node bin/cucumber.js --tags \"not @source-mapping\" && nyc report --reporter=lcov",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The nyc instrumentation seems to mess these scenarios up when we check for coverage. We could try and fix up the environment for the child process but it didn't feel worth it.

@davidjgoss davidjgoss merged commit 4ea3227 into main Nov 12, 2022
@davidjgoss davidjgoss deleted the feat/nodejs-source-maps branch November 12, 2022 16:17
@davidjgoss
Copy link
Contributor Author

This was released in 8.8.0 https://github.com/cucumber/cucumber-js/releases/tag/v8.8.0

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.

None yet

2 participants