This should not happen but it does. Did not manage to find the real source but it seems ok to test it here. Plus if it happens the measurement chain for that view will be broken
It comes with a major refactoring of the BorderDrawable. Now all Paths are cached not to regenerate them on every draw pass.
Also it is important to understand that the clipping feature on android comes at a cost.
It will be done only when truelly necessary. but with complex paths ((border radius > 0 && border non uniform) || border-width >0) then we must apply a costly drawing pass (though hardware accelerated) to accomplish it.
* feat: use raw-loader for all css but app.s?css
* feat: use angular css rules for entire app dir
Co-authored-by: Eduardo Speroni <edusperoni@gmail.com>
* fix(webpack): Fail build in case of compilation errors.
WebPack's own documentation states that the `err` object **will not**
include compilation errors.
https://webpack.js.org/api/node/#webpack
This fix addresses compilation errors by setting the correct `process.exitCode`
looking at the result of the `stats.hasErrors()` call.
* fix(tsc): Ensure that TypeScript compilation errors are handled.
The `async` flag of the `fork-ts-checker-webpack-plugin` will (by default
in development mode) avoid reporting any errors detected by `tsc` back
to webpack:
https://github.com/TypeStrong/fork-ts-checker-webpack-plugin#options
> If `true` reports issues **after** webpack's compilation is done.
> Thanks to that it doesn't block the compilation.
The problem in this case is that any compilation error will be then
undetectable by the `WatchStatePlugin` which will happily tell the
NativeScript CLI to continue with the build process.
* fix(cli): Do not send the `compilation` message to the CLI on errors.
When the compilation fails, this patch will prevent for the `compilation`
message to be sent back to the CLI, preventing broken builds hitting the device.
