This displays a user error if the reading the image causes an error,
instead of letting it fall through and get reported.
This is to avoid reporting errors that are not due to malfunction of the software,
but due to malformatted images.
Change-Type: minor
Changelog-Entry: Display nicer error dialog when reading an invalid image
This changes the test cases to just return the Promises,
to avoid timing out on failures and to provide better
error messages and stack traces.
Change-Type: patch
There are a lot of new rules since the last time I revised the ESLint
rules documentation.
I've updated the main `.eslintrc.yml` to include some newer additions,
plus I added another ESLint configuration file inside `tests`, so we can
add some stricted rules to the production code while relaxing them for
the test suite (due to the fact that Mocha is not very ES6 friendly and
Angular tests require a bit of dark magic to setup).
This is a summary of the most important changes:
- Disallow "magic numbers"
These should now be extracted to constants, which forces us to think of
a good name for them, and thus make the code more self-documenting (I
had to Google up the meaning of some existing magic numbers, so I guess
this will be great for readability purposes).
- Require consistent `return` statements
Some functions relied on JavaScript relaxed casting mechanism to work,
which now have explicit return values. This flag also helped me detect
some promises that were not being returned, and therefore risked not
being caught by the exception handlers in case of errors.
- Disallow redefining function arguments
Immutability makes functions easier to reason about.
- Enforce JavaScript string templates instead of string concatenation
We were heavily mixing boths across the codebase.
There are some extra rules that I tweaked, however most of codebase
changes in this commit are related to the rules mentioned above.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The `image-stream` module currently returns a readable stream, a
transform stream, a "size", and an optional "estimatedUncompressedSize".
Based on this information, its hard to say what "size" represents. Some
format handlers return the compressed size and provide a decompression
transform stream while others return the decompressed stream directly
and put the decompressed size in "size".
As a way to simplify this, every format handler now returns a "size"
object with the following properties:
- `original`: The original compressed size
- `final.estimated`: Whether the final size is an estimation or not
- `final.value`: The final uncompressed size
As a bonus, we extract the file size retrieval logic to
`imageStream.getFromFilePath()`, which is the onlt part where the
concept of a file should be referred to.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is a long lasting task. The `etcher-image-stream` project takes
care of converting any kind of image input into a NodeJS readable
stream, handling things like decompression in betwee, however its a
module that, except for weird cases, there is no benefit on having
separate from the main repository.
In order to validate the assumption above, we've left the module
separate for almost a year, and no use case has emerged to keep it
like that.
This commit joins the code and tests of that module in the main
repository.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
