Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Convert other errors to diagnostics when possible #183
Convert other errors to diagnostics when possible #183
Changes from 6 commits
a6e167f
6910969
e02c6bb
f42c30b
3930f02
0b77f65
8de3d79
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like a difference here is that we used to generate a display label for each script that was always relative to the current package (see
DefaultLogger.#label
), so that everything was phrased relative to where the user currently is. But now it uses the verbatim specifier from the dependency array, which is relative to each package.Also, we'll probably support
$WORKSPACES:build
syntax (#23), to mean "all build scripts in this package's workspaces". So in that case, the literal dependency specifier wouldn't actually tell you what the specific package is.So I think it might be good to preserve the
DefaultLogger.#label
method behavior?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, but the printed trail has the filenames relative to the current package so that you can follow along. Like, if we there was a cycle of "foo" -> "build" -> "$WORKSPACES:build" -> "./child:build" -> "foo" then the diagnostic printer would print (leaving out line and column numbers):
Or in the case where the loop is more like "./child:build" -> "./child:foo" -> "build" -> "$WORKSPACES:build" and starting from the
child
directory then it would like:That's a bit harder to read. Maybe we'd want that last line to read more like this?
What would your ideal error message look like?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we could generate a diagnostic for the IDE with all the supplemental locations but keep the previous error formatting in the logger
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I see it is not so simple.
Was sort of thinking something like this:
I do like that it's just a single, consistent syntax for referring to a script, which matches exactly how you would specify that script in the package you started from.
But then we lose the package.json references, which are required and/or useful? If you keep them but use the consistent script specifier, then it seems sort of confusing because it's no longer relative to each line's package.json.
Meh, I'm also fine with it the way it already was in this PR.
I kind of liked the cycle diagram (which is actually taken exactly from Bazel), but it's also really nice to have symmetrical errors on the console vs in the editor, so I'm fine with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The package.json references are useful so that someone can cmd-click on them to jump directly to that specific location, as well as to power the supplemental locations feature in the language server provider, which does fancy presentation of the diagnostic in the editor.
One other consideration is that this way of displaying it is much wordier and longer than the cycle diagram, but I feel like cycles are rare in the wild, and when you do have one it's better for it to be longer like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could collapse some or all of these validation error interfaces into one, now that the formatter isn't really responsible for formatting them anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(doesn't have to be this PR, just a thought)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😢