-
Notifications
You must be signed in to change notification settings - Fork 63
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
Less aggressive error reporting? #4
Comments
I've never really found node.js stack traces to be very useful at all. However, I don't think it's necessarily a node.js problem. It's weeding through the exceptions bubbled up from the package dependency chain; you better have some time to kill. At least in my experience. I'll leave it open for suggestions. And thanks for the feedback! |
I suppose my suggestion would be, if possible, take the top line of the traceback (or "Prettier failed to parse file") and display it in the status bar at the bottom of the screen and let it fail basically silently. It's not mission critical to have prettier always succeed and linting can show where the actual failure is. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Firstly, thank you for jumping on making prettier work with sublime. Much appreciated!
However, currently if there is something that can't be parsed in the source file then this package will throw up a dialog with the entire prettier traceback. That traceback is largely useless to understand where the code doesn't parse, but pretty annoying, especially when the package is set to run prettier on save. I'm wondering if there's a more subtle alternative?
The text was updated successfully, but these errors were encountered: