The example in the code snippet below this line of text shows `ActivatedRouter` being injected into a component's constructor. When I read instruction to inject A`ActivatedRouter` into **application's** constructor, I assumed this meant the constructor for `app.component.ts`.
Editing to clarify/match code example below.
PR Close#49270
If a class is declared in multiple modules, the standalone migration may end up generating invalid code. While declaring a class in multiple modules is an error, it can happen with modules in tests. These changes avoid the issue by using a `Set` to track the classes being migrated.
PR Close#49245
Add a more specific error message when defining a lazy-loaded route using
`loadComponent` and passing it a NgModule instead of a standalone component,
when the user should actually be using `loadChildren`.
PR Close#49164
Fix the function stripping the base path from the URL, as the current implementation uses the base path as part of a regex, which wrongly makes paths fails that contain characters such as a parenthesis (example: C:/Users/MyUser(Test)/project).
Fixes#49179
PR Close#49181
This commit updates the `TNode` to include a reference to the previous sibling node. Currently, TNode has references to the next sibling and parent nodes, but in followup changes we'd need to have access to previous TNodes (to determine position of the current node).
PR Close#49223
This commit updates the TransferState class to move its init logic from the `useFactory` function to its constructor. The change is needed to make the init behavior consistent across different injection scenarios and tolerate the issue described in https://github.com/angular/angular/issues/49190.
PR Close#49191
This commit updates the `elementStart` instruction to avoid creating DOM nodes before creating a corresponding TNode. This refactoring is needed to make sure this internal logic is consistent across all instructions.
PR Close#49172
Consider the following scenario:
1. A TS file with a component and templateUrl exists
2. The template file does not exist.
3. First build: ngtsc will properly report the error, via a FatalDiagnosticError
4. The template file is now created
5. Second build: ngtsc still reports the same errror.
ngtsc persists the analysis data of the component and never invalidates
it when the template/style file becomes available later.
This breaks incremental builds and potentially common workflows
where resource files are added later after the TS file is created. This
did surface as an issue in the Angular CLI yet because Webpack requires
users to re-start the process when a new file is added. With ESBuild
this will change and this also breaks incremental builds with
Bazel/Blaze workers.
To fix this, we have a few options:
* Invalidate the analysis when e.g. the template file is missing. Never
caching it means that it will be re-analyzed on every build iteration.
* Add the resource dependency to ngtsc's incremental file graph. ngtsc
will then know via `host.getModifiedResources` when the file becomes
available- and fresh analysis of component would occur.
The first approach is straightforward to implement and was chosen here.
The second approach would allow ngtsc to re-use more of the analysis
when we know that e.g. the template file still not there, but it
increases complexity unnecessarily because there is no **single**
obvious resource path for e.g. a `templateUrl`. The URL is attempted
to be resolved using multiple strategies, such as TS program root dirs,
or there is support for a custom resolution through
`host.resourceNameToFileName`.
It would be possible to determine some candidate paths and add them to
the dependency tracker, but it seems incomplete given possible external
resolvers like `resourceNameToFileName` and also would likely not have
a sufficient-enough impact given that a broken component decorator is
not expected to remain for too long between N incremental build
iterations.
PR Close#49184
Adds some logic to automatically delete `export * from './foo'` style imports. Previously they weren't being picked up, because finding all the references using the language service doesn't include barrel exports.
PR Close#49176
The `standalone-bootstrap` migration now migrates `HttpClientModule` imports to `provideHttpClient(withInterceptorsFromDi())` instead of `importProvidersFrom(HttpClientModule)`.
The `withInterceptorsFromDi()` feature is added to make sure class-based interceptors still works if there are any in the application.
Fixes#48948
PR Close#48949
un-commented tags are responsible for rendering problem of markdown document. This commit fixes the http make jsonp request guide.
fixes#49151
PR Close#49152
Since we have less information about how to copy test components, we copy all the `imports` from the `configureTestingModule` call into the component's `imports`. It fixes some tests, but it can cause issues with animations modules, because they throw errors if they're imported multiple times.
These changes add an exception for animations modules imported in testing modules.
PR Close#49147
Very cosmetic, but it might be necessary :
I updated the ```canAccess``` method second signature name and type in the provided sample. As it stands, it triggers `TS(2345): Argument of type 'Route' is not assignable to parameter of type 'string'`.
PR Close#49140
Fixes that the `ImportManager` was returning the `propertyName` instead of the `name` when there's an import with a conflicting identifier.
PR Close#49139
Ocasionally Node is randomly not installed in the Windows job. We've
been trying to debug this for a while. With the additonal debug
information it looks like in some situations the NodeJS folder from
NVM is not even present.
One idea is to use `nvm on` to ensure NVM is actually enabled. It's
unclear why it would be `off` at VM start, but it's worth giving a try.
Trying `nvm off` via SSH yields similar issues as we saw in the flaky
workflows:
https://app.circleci.com/pipelines/github/angular/angular/56160/workflows/2f1b80b3-29c7-4274-804e-cb994c20aff0/jobs/1287228
PR Close#49142
Andrew Kushnir