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

Handle errors from build_runner tasks #1284

Closed
DanTup opened this issue Oct 31, 2018 · 4 comments
Closed

Handle errors from build_runner tasks #1284

DanTup opened this issue Oct 31, 2018 · 4 comments
Labels
in tasks Relates to VS Code tasks, such as those provided by Task Providers is enhancement
Milestone

Comments

@DanTup
Copy link
Member

DanTup commented Oct 31, 2018

For ex. if pub get hasn't been run or you delete .dart_tool and leave generated files, it shouldn't just act as if everything was successful and silently run.

@DanTup DanTup added is enhancement in tasks Relates to VS Code tasks, such as those provided by Task Providers labels Oct 31, 2018
@DanTup DanTup added this to the v2.21.0 milestone Oct 31, 2018
DanTup added a commit that referenced this issue Nov 13, 2018
@DanTup
Copy link
Member Author

DanTup commented Nov 13, 2018

Pushed some changes that detect when the build fails (or rather, than it finished with failure - whereas before it just didn't realise the build had finished), and also parses errors out to make squiggles (note: it's not as slow as the badly-converted gif makes it seem!).

build_runner

@jakemac53 @natebosch this relies on parsing the output with regex (see dart-lang/build#1167 (comment)) but since this feature is still behind a flag (and requires you invoke the command manually or from a preLaunchTask) I'm probably going to include this update in the next release. It'd be good if we could agree something less fragile before it's un-flagged though (it's really neat if you're using it for things like JSON having it build-on-save and show errors directly in the editor :-))

@jakemac53
Copy link

It is pretty trivial to do custom reporting, what format would you like?

Essentially inside the build and watch methods we create a stdIOLogListener today unless you provide a custom onLog(LogRecord record) method.

We could either add another named argument to those methods (maybe a new LogFormat enum?) and create a different logger, or we can handle it inside the command implementations via the SharedOptions and pass the custom onLog method.

The actual implementation of the logger could live either in build_runner_core or build_runner.

If you wanted to send a PR yourself we could help get that through, or if you could give us your desired format that works also.

@DanTup
Copy link
Member Author

DanTup commented Nov 13, 2018

Any format that's easily parseable would be fine but the less ambiguous the better.

Looking at the docs, the fields I can parse are:

  • file
  • line/column or full location (must be in form startLine,startColumn,endLine,endColumn)
  • message
  • severity (a string of "error", "warning" or "info")
  • code

Something similar to the current output but a bit more structured could be:

[INFO] Build Started // Consistent start marker
[ERROR]
    file: some/file/path.dart
    location: 1,1,1,30
    code: error_code
    message: You did something wrong
[WARNING]
    file: some/file/path.dart
    location: 1,1,1,30
    code: warn_code
    message: You did something slightly wrong
[INFO] Build Complete // Consistent end marker, whether it was success or fail

It could be condensed a little if wanted too - like putting location after the filename and maybe rolling up onto the previous line (we can make a regex reliably match that with anchoring to start/end of lines).

There could be additional summaries if you want it more user-friendly (the user will see this output in their Terminal pane in VS Code as well as us parsing it) that just won't match our regex:

[INFO] Build succeeded after blah...
[SEVERE] Build failed after blah...

It's a bit sucky that the location and the error/warning/info need to be in specific formats (since it makes this output somewhat controlled by VS Code) but for the improved integration maybe it's worthwhile.

If it's easy for you to do and you have the capacity, you might be quicker at it than me getting up to speed, but if you're busy I don't mind having a go if you can point me in the right direction (and decide which way you'd prefer from the options you listed).

@DanTup DanTup modified the milestones: v2.21.0, v2.22.0 Nov 22, 2018
@DanTup DanTup modified the milestones: v2.22.0, On Deck Dec 17, 2018
@DanTup DanTup modified the milestones: On Deck, v3.7.0 Oct 24, 2019
@DanTup DanTup modified the milestones: v3.7.0, v3.8.0 Nov 19, 2019
@DanTup DanTup modified the milestones: v3.8.0, v3.9.0 Jan 2, 2020
@DanTup DanTup modified the milestones: v3.9.0, On Deck Mar 11, 2020
@DanTup DanTup modified the milestones: On Deck, v3.16.0 Oct 1, 2020
@DanTup DanTup modified the milestones: v3.16.0, v3.17.0 Oct 21, 2020
@DanTup
Copy link
Member Author

DanTup commented Nov 2, 2020

I'm removing the preview flag for build_runner work in the next release. I'm going to ship this as-is (with a few tweaks) for now. If a better way to get errors is possible in future, we can update it - but it seems to work fine for now with my testing.

@DanTup DanTup closed this as completed Nov 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in tasks Relates to VS Code tasks, such as those provided by Task Providers is enhancement
Projects
None yet
Development

No branches or pull requests

2 participants