Feature/build server

[HenrikThoroe]

• Exposes compiler via web socket API
• Manages
  • many-clients one-project
  • many-clients many-projects
• Resource management by assigning each project a custom isolate
• Includes utilities for easier async event handling

[HenrikThoroe]

VHook

Don't get me wrong, it's a good tool. But for now it's lacking a few important functionalities and produces quite a bit overhead.
Would be nice if you could improve on it. If you don't have time I could do it as well.

Below I listed what I currently miss.

Overhead

// Would be nice to combine expect and awaitValue methods
await hook.expect(equals(*), timeout: Duration(years: 42));

// For now we have to use a two-liner for this
await hook.awaitValue(Duration(years: 42));
hook.expect(equals(*));

Functionality

• Have to use bool? if I only want to distinguish between two states.
• No replacement for Completer.completeError
• If my value can be null I cannot await it
• I'd like to await based on the value and not be limited to null checks. For example awaitValue(Duration(years: 42), (value) => condition)

[HenrikThoroe]

Protocol Messages

I don't think we should test if JsonSerializable is doing it's job. I think the only reasonable tests for protocol messages are tests of custom methods and tests if everything is available in ProtocolDelegate.

[Coronon]

ProtocolMessage

I would at least like some kind of check if a message is equal to itself after serialization and deserialization as this could discover errors made by us, the programmers.

[Coronon]

VHook

Those VHook features seem like a great idea. I’ll attempt to implement them this week. I could actually need them too :)

[HenrikThoroe]

Answer to #9 (comment)

I do have one presumption on which my opinion is based:
We trust the json_serializable package.

That said we've got the following components in the message lifecycle:

1. Conversion to JSON map
2. Conversion to string which carries the type
3. Conversion back to a map and getting the correct type without explicit type annotation
4. Conversion back to an object

Step 1 and 2 don't have to be tested because the presumption. Step 2 and 3 need testing but in the scope of ProtocolDelegate which performs those steps. If we verify that ProtocolDelegate can do that on every possible object the only thing left to check is that our new message types are available in ProtocolDelegate.elements. All further tests would just test json_serializable.

[Coronon]

Answer to #9 (comment)

But testing json_serializable is not that bad of an idea. I don’t mean the actual serialization but rather the custom behaviour (key names, defaults etc.) set by us developers.