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
Merged

Conversation

@GrygrFlzr
Copy link
Member

@GrygrFlzr GrygrFlzr commented Jul 14, 2021

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
}

This comment has been minimized.

@aleclarson

aleclarson Jul 14, 2021
Member

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

This comment has been minimized.

@GrygrFlzr

GrygrFlzr Jul 14, 2021
Author Member

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

This comment has been minimized.

@aleclarson

aleclarson Jul 14, 2021
Member

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-js patak-js merged commit 887c247 into main Jul 14, 2021
6 checks passed
6 checks passed
@github-actions
Build&Test: node-12, ubuntu-latest
Details
@github-actions
Build&Test: node-14, ubuntu-latest
Details
@github-actions
Build&Test: node-16, ubuntu-latest
Details
@github-actions
Build&Test: node-14, macos-latest
Details
@github-actions
Build&Test: node-14, windows-latest
Details
@github-actions
Lint: node-14, ubuntu-latest
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants