perf: tree-shake errors and warnings in production mode

[arturovt]

Hey! I've guarded all warnings and errors with ngDevMode in the same way as Angular guards warnings and errors internally (thus they can be tree-shaken by Terser when app (not lib) is built in production mode).

Before:

After:

[codecov-commenter]

Codecov Report

Merging #92 (3b70829) into master (1c2042a) will decrease coverage by 0.04%.
The diff coverage is 90.90%.

@@            Coverage Diff             @@
##           master      #92      +/-   ##
==========================================
- Coverage   84.13%   84.09%   -0.05%     
==========================================
  Files          30       30              
  Lines         435      440       +5     
  Branches       57       63       +6     
==========================================
+ Hits          366      370       +4     
- Misses         69       70       +1     

Impacted Files	Coverage Δ
...-element-dynamic/lazy-element-dynamic.directive.ts	45.61% <75.00%> (+0.15%)	⬆️
...zy-elements/lazy-element/lazy-element.directive.ts	82.00% <100.00%> (+0.36%)	⬆️
.../lib/lazy-elements/lazy-elements-loader.service.ts	97.61% <100.00%> (+0.05%)	⬆️
...ents/src/lib/lazy-elements/lazy-elements.module.ts	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1c2042a...3b70829. Read the comment docs.

[tomastrajan]

@arturovt is this something which is considered best practice ? eg how would it look like in prod when those cases happen ?

But if its all good and expected we can ofcourse merge

[arturovt]

Well, if the user is doing something, those errors will be thrown in development mode. E.g. if forRoot() is called twice, the user will see the error in development mode, so there is no sense to throw it in production. Or if the config is duplicated, the user will see the warning in development mode or if the tag binding hasn't been provided.

I wouldn't say that tree-shaking is some best practice; this is something that all libraries are trying to achieve to decrease the final bundle size, e.g. considering how Angular tree-shakes all errors and warnings internally (since everything is wrapped with ngDevMode guard) or how React provides dev and prod bundles considering NODE_ENV variable.

[tomastrajan]

@arturovt thank you, as long as this follows what angular does it should not be too confusing for the developer experience