Reproducing Dav's comments from issue #1

However, it should be required that the code live in the json file and optted out for performance. That
way you can generate reports from the JSON file in the future without having the code provided. If all
the relevant data is in the JSON file, then istanbul can generate an lcov file and a directory structure
based on what's in the JSON file.

It's kind of a catch 22, the lcov file isn't good for long term storage if the files that it's instrumented are
different and are required to generate the report. So storing the code in the JSON file as a permanent
place to restore that report from seems like it's a better option.

Personally, I'm not a big fan of packing code into the coverage object by default. Especially for the browser testing use case where, IMO, the goal should be for the instrumented code to be as small as possible to reduce the test latency.

The approach I favor is to support a new zip command, that is run after all the tests which, at a high level, stores enough state to reproduce all the reports at a future point in time. Note that I did not say "packs code into the coverage object" since with hundreds of files all the code + coverage may not fit into memory.

The state could, instead, be a zip file containing a bunch of JSON coverage files and a bunch of source files all packed in. The file paths in the coverage objects are mangled so that they relatively reference the source files.

I must admit a lot more thinking/ discussion is required on my part to crystallize this. Feedback is most welcome.