-
Notifications
You must be signed in to change notification settings - Fork 108
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
Changes from all commits
a6e167f
6910969
e02c6bb
f42c30b
3930f02
0b77f65
8de3d79
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -114,15 +114,9 @@ export class DefaultLogger implements Logger { | |
break; | ||
} | ||
case 'invalid-json-syntax': { | ||
console.error( | ||
`❌${prefix} Invalid JSON syntax in package.json file in ${event.script.packageDir}` | ||
); | ||
break; | ||
} | ||
case 'invalid-package-json': { | ||
console.error( | ||
`❌${prefix} Invalid JSON in package.json file in ${event.script.packageDir}` | ||
); | ||
for (const diagnostic of event.diagnostics) { | ||
console.error(this.#diagnosticPrinter.print(diagnostic)); | ||
} | ||
break; | ||
} | ||
|
||
|
@@ -132,17 +126,11 @@ export class DefaultLogger implements Logger { | |
); | ||
break; | ||
} | ||
case 'script-not-found': { | ||
console.error( | ||
`❌${prefix} No script named "${event.script.name}" was found in ${event.script.packageDir}` | ||
); | ||
break; | ||
} | ||
case 'script-not-wireit': { | ||
console.error(this.#diagnosticPrinter.print(event.diagnostic)); | ||
break; | ||
} | ||
case 'invalid-config-syntax': { | ||
case 'script-not-found': | ||
case 'duplicate-dependency': | ||
case 'script-not-wireit': | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. (doesn't have to be this PR, just a thought) |
||
case 'invalid-config-syntax': | ||
case 'cycle': { | ||
console.error(this.#diagnosticPrinter.print(event.diagnostic)); | ||
break; | ||
} | ||
|
@@ -156,12 +144,7 @@ export class DefaultLogger implements Logger { | |
); | ||
break; | ||
} | ||
case 'duplicate-dependency': { | ||
console.error( | ||
`❌${prefix} The dependency "${event.dependency.name}" was declared multiple times` | ||
); | ||
break; | ||
} | ||
|
||
case 'signal': { | ||
console.error(`❌${prefix} Failed with signal ${event.signal}`); | ||
break; | ||
|
@@ -170,32 +153,6 @@ export class DefaultLogger implements Logger { | |
console.error(`❌${prefix} Process spawn error: ${event.message}`); | ||
break; | ||
} | ||
case 'cycle': { | ||
console.error(`❌${prefix} Cycle detected`); | ||
// Display the trail of scripts and indicate where the loop is, like | ||
// this: | ||
// | ||
// a | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 😢 |
||
// .-> b | ||
// | c | ||
// `-- b | ||
const cycleEnd = event.trail.length - 1; | ||
const cycleStart = cycleEnd - event.length; | ||
for (let i = 0; i < event.trail.length; i++) { | ||
if (i < cycleStart) { | ||
process.stderr.write(' '); | ||
} else if (i === cycleStart) { | ||
process.stderr.write(`.-> `); | ||
} else if (i !== cycleEnd) { | ||
process.stderr.write('| '); | ||
} else { | ||
process.stderr.write('`-- '); | ||
} | ||
process.stderr.write(this.#label(event.trail[i])); | ||
process.stderr.write('\n'); | ||
} | ||
break; | ||
} | ||
} | ||
break; | ||
} | ||
|
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.