Prior to this patch, if an element is queried and animated for 0 seconds
(just a style() call and nothing else) then the styles applied would not
be properly cleaned up due to their camelCased nature.
PR Close#23633
When running `yarn start` and `yarn serve-and-sync`, we are usually
more interested in faster re-build times than optimized builds. This was
also the behavior, before upgrading to @angular/cli@6 (fc5af69fb).
This commit introduces a new configuration (`fast`), which is used by
`yarn start` and `yarn serve-and-sync` to restore the faster,
unoptimized builds.
Other commands, such as `ng serve` and `ng e2e`, remain unchanged (using
slower, optimized builds).
PR Close#23569
Fix a corner case where eager providers were getting constructed twice if the provider was requested before the initialization of the NgModule is complete.
PR Close#23559
g3 and the Angular repo have different versions of TypeScript, and
ts.updateIdentifier() has a different signature in the different versions.
There is no way to write a call to the function that will compile in both
versions simultaneously.
Instead, use ts.getMutableClone() as that has the same effect of cloning
the identifier.
PR Close#23550
This commit adds a new compiler pipeline that isn't dependent on global
analysis, referred to as 'ngtsc'. This new compiler is accessed by
running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization
logic but creates a new implementation of Program which does not perform the
global-level analysis that AngularCompilerProgram does. It will be the
foundation for the production Ivy compiler.
PR Close#23455
`ng.performCompilation` can return an `undefined` program, which is not handled by ngc-wrapped.
Avoid crashing by checking for the error return and returning the diagnostics.
PR Close#23468
Temporary workaround for angular/angular-cli#10398.
The behavior of `yarn build` remains the same, but building for a
specific deployment env (e.g. archive, next) requires
`yarn build-for $deployEnv`.
PR Close#23470
The bug fixed here steams from the fact that we are traversing too far up
in the views tree hierarchy in the destroyViewTree function.
The logic in destroyViewTree is off if we start removal at an embedded view
without any child views. For such a case we should just clean up (cleanUpView)
this one view without paying attention to next / parent views.
PR Close#23482
Igor Minar
Alex Eagle
Matias Niemelä
Brandon Roberts
Alex Eagle
jenniferfell
Igor Minar
Vani
George Kalpakas
Ardeshir81
Camilo Giraldo
Anuj
Andrew Seguin
Kara Erickson
Misko Hevery
Sarun Intaralawan
Olivier Combe
Bennett Hardwick
Victor Berchet
Judy Bogart
Vikram Subramanian
Marc Laval
Alex Rickabaugh
Noah Medling
Paul Freedman
Martin Probst
Pawel Kozlowski