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

fix(dev): only rewrite SSR stacktrace when possible #4248

Merged
merged 2 commits into from Jul 14, 2021

Conversation

GrygrFlzr
Copy link
Member

Current Behavior

ssrFixStacktrace(e) {
if (e.stack) {
e.stack = ssrRewriteStacktrace(e.stack, moduleGraph)
}
},

e.stack = ssrRewriteStacktrace(e.stack, moduleGraph)
server.config.logger.error(
`Error when evaluating SSR module ${url}:\n${e.stack}`,

Currently, Vite assumes that the stack property of an error will always be writable. Unfortunately, this is not always the case, as seen here in the discord-oauth2 module:

Object.defineProperty(this, "stack", {
    value: this.message + "\n" + stack,
    writable: false,
});

This leads to errors inside ssrFixStacktrace:

TypeError: Cannot assign to read only property 'stack' of object 'DiscordHTTPError: 400 Bad Request on POST /api/v7/oauth2/token'

Proposed Behavior

  1. Check if the property is configurable (i.e. redefinable with Object.defineProperty). If so, redefine the property.
  2. Otherwise, check if the property is writable. If so, perform assignment to the property.
  3. If all else fails, leave the stacktrace untouched.

As ssrFixStacktrace is an in-place operation, we cannot return a new error object with the redefined stack-trace. I am unsure if there's a better way to handle this.


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the Commit Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

@GrygrFlzr GrygrFlzr changed the title fix(dev): only rewrite error stacktrace when possible fix(dev): only rewrite SSR stacktrace when possible Jul 14, 2021
})
} else if (writable) {
e.stack = stacktrace
}
Copy link
Member

Choose a reason for hiding this comment

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

Should we warn if neither configurable nor writable, so the dependency gets fixed?

Copy link
Member Author

@GrygrFlzr GrygrFlzr Jul 14, 2021

Choose a reason for hiding this comment

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

Hm, emitting the warning properly would require server instance, which wouldn't be accessible inside rebindErrorStacktrace. Would it be better to:

Pass in a server instance to have rebindErrorStacktrace emit the warning?

function rebindErrorStacktrace(e: Error, stacktrace: string, server: ViteDevServer): void

Return a boolean for success and have the respective consumers emit the warning? There probably would also be more context available for more detailed errors.

function rebindErrorStacktrace(e: Error, stacktrace: string): boolean

Copy link
Member

Choose a reason for hiding this comment

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

I'm thinking we should deprecate ssrRewriteStacktrace in favor of a SSRError extends Error subclass whose constructor takes a stack trace string. So for now, I vote to merge this PR as-is.

@patak-dev patak-dev merged commit 887c247 into main Jul 14, 2021
aleclarson pushed a commit to aleclarson/vite that referenced this pull request Nov 8, 2021
@antfu antfu deleted the best-effort-stacktrace branch December 24, 2021 05:03
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

3 participants