By not jumping through the extra hoop imposed by BufReader/BufWriter, we can more easily directly modify the elm.json file.
I doubt reading/writing are bottlenecks in our application, so using the file directly rather than going through the buffered implementations is extremely unlikely to result in any kind of noticeable performance drop.
An alternative solution would be to add a custom formatter that keeps track of the object depth and writes out an extra newline after closing the top-level object. See this issue for an example implementation.
This would make the formatting reusable, but raises the question whether adding a newline at the end is a json-formatting thing, or a file-level thing. I'm leaning towards "file-level concern", so let's go with that for now!
i got pretty close to this because, after reading the BufWriter docs, it seemed unnecessary. i'm not sure what i got stuck on, but i'm glad this is in. thank you!
By not jumping through the extra hoop imposed by BufReader/BufWriter, we can more easily directly modify the elm.json file.
I doubt reading/writing are bottlenecks in our application, so using the file directly rather than going through the buffered implementations is extremely unlikely to result in any kind of noticeable performance drop.
An alternative solution would be to add a custom formatter that keeps track of the object depth and writes out an extra newline after closing the top-level object. See this issue for an example implementation.
This would make the formatting reusable, but raises the question whether adding a newline at the end is a json-formatting thing, or a file-level thing. I'm leaning towards "file-level concern", so let's go with that for now!
Fixes #23