-
Notifications
You must be signed in to change notification settings - Fork 28.7k
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
Explore future direction of the task runner system. #15179
Comments
Some things I'd love to support in Dart Code: BuildsIf running a 'watching build' (similar to TypeScript - something transpiling Dart to JS) would like to know when the user hits Tests
These last two can probably be handled by something similar to a "watching build", but it would need to know when build finishes to reliably run the JS tests at the same time (I guess this would be the same if you supported TypeScript run-on-build tests). I'd also really love to be able to output test results in some structured format so Code code display them nicely (not just terminal text output) and allow clicking to navigate to the test (or correct location if it crashed with a stack trace). This is out of scope for this case (and possibly for Code entirely) but maybe worth having thought about if changing how testing is configured. |
I created an issue for moving tasks to use the terminal instead of an output channel #15584 which solves many of these issues. |
May I also suggest that current limitations be more visibly disclosed in the documentation? I for one was struggling for a couple of hours yesternight trying to have background tasks functioning "as expected" :( |
Also, it's not quite clear why is it impossible (or seems impossible) to be able to run AND return (without waiting forever) for a spawned background processes. Should I create a separate issue on this ? |
Quite some work has happened for January here. It is:
|
Cool! Any chance we will get a Side bar view for Tasks? For such an important part of VSCode, tasks are kind of buried. I can imagine a UI that shows tasks, allows you to run them, edit them, add them, delete them. And perhaps view the output of the last run of each. And it would indicate a running task and provide a way to terminate execution of the task. At the very least, how about a predefined kbd shortcut for |
@agc93 fyi... |
A lot of progress has happened and we will provide a polished task 2.0.0 in June. |
@dbaeumer Is this something we can start looking at in Insiders? Is there a good place for info on how it works? Thanks! |
@DanTup the doc has not been written yet but the best place will be the 1.14 release notes. For the API you can already start looking at the vscode.proposed.d.ts in the source tree. |
@dbaeumer Great; thanks! |
Will keep the item open for August. Most of the stuff discussed in here is now in the 1.14 build. |
@dbaeumer woot! Have started playing around with the new stuff for integrating Cake tasks. Looking forward to getting this pushed out. 👍 |
Moving to on deck. There is still some final polish work to do here. |
I am closing the issue. Please open new issues if there is something wrong or missing with the task 2.0.0. Having a single large item is very hard to act upon. |
THIS IS WORK IN PROGRESS
This issue will be used to discuss the future direction of the task runner system in VS Code.
History
The task runner system in VS Code got introduce in one of the first public releases of VS Code to allow calling out to an external program to do some work (building, compiling, running tests, upload, publish). Besides running the external program the task running system parsed the output to produce problem markers (errors, warnings and info messages).
When introduced there was no extension API available nor a terminal.
Current Limitations
The task running framework has currently the following major limitations:
Open Questions
Do we need more than one build task?
There are two major reasons for this
Having one build task which trigger gulp watch and then saving changes to a ts and less file with Save All produces the following single output.
Assigning errors to the correct problem matcher is again problematic may be even impossible if a problem matcher is a multi line matcher (e.g matcher for example the lines ["Compiling less file 0","Compiling less file 1"]
To handle this the watch-less and the watch-ts task are best execute as two separate tasks. Without an integration in VS Code dev would usually start the two gulp task in two different terminals to keep the output separate for readability as well.
Proposal
Build and Co.
First we should decouple task executing from build, rebuild, clean, run tests. The task runner should be able to participate in these commands however it shouldn't be the main driver of these commands. Using the Build command as an example this should work as follows:
Dependency management
If we have more than one build participant or even two independent build tasks the question raises if we need to define the order of the executed participants or build tasks. We have the following options:
Open question:
Executing an external tool
External tool tasks should be executed in a terminal instead of being executed
hidden
with its output made available in an output channel. This will allow us to support ANSI control characters, input, ...The text was updated successfully, but these errors were encountered: