Open augustl opened 9 years ago
This will probably require a 2.0 release of ramp and ramp-resources. I don't see why we would keep the old serialization API, both buster-static and buster-server can use the imagined lazy streaming API.
It makes sense to keep the API surface of ramp resources mostly intact for the things various extensions uses it for. I want to make it immutable, so some minor changes may be required. A mutable builder API could help mitigate this, so the only change you need to make is to finalize the builder at the end.
Lazy-loading of resources could also affect the buster-istanbul
extension, which processes each resource that is sent to the browser to capture code coverage.
Good point!
The idea is to still allow for a content function that does whatever. But instead of invoking this and serializing every resource in advance, buster-server asks buster-test for the files it actually loads, on-demand. That way, the function will run just like before, inside the buster-test process, so it should work just fine.
@augustl, is the issue #399 related to this issue?
The current process is to serialize the entire resource set to JSON from the buster-test end, and ship it to the buster-server over HTTP.
This issue tracks the progress of rewriting Buster (specifically, ramp and ramp-resources) to have a lazy approach instead.
The downsides of the current approach is:
The downsides of a lazy approach is: