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
This change makes the `createUrlTreeFromSnapshot` added in #45877 the
default and only behavior in the Router. This now addreses #42191, #38276, #22763,
and #48472 without needing to create custom handling to
call `createUrlTreeFromSnapshot` (since it's now called by `Router.createUrlTree`).
BREAKING CHANGE: Tests which mock `ActivatedRoute` instances may need to be adjusted
because Router.createUrlTree now does the right thing in more
scenarios. This means that tests with invalid/incomplete ActivatedRoute mocks
may behave differently than before. Additionally, tests may now navigate
to a real URL where before they would navigate to the root. Ensure that
tests provide expected routes to match.
There is rarely production impact, but it has been found that relative
navigations when using an `ActivatedRoute` that does not appear in the
current router state were effectively ignored in the past. By creating
the correct URLs, this sometimes resulted in different navigation
behavior in the application. Most often, this happens when attempting to
create a navigation that only updates query params using an empty
command array, for example `router.navigate([], {relativeTo: route,
queryParams: newQueryParams})`. In this case, the `relativeTo` property
should be removed.
PR Close#48508
This commit moves the `TransferState` class implementation to `@angular/core`. This class will be needed in core in followup changes and `core` can not depend on `platform-browser` package.
The `core` package does **not** export those symbols into public API surface.
The `platform-browser` package re-exports the symbols under same names for backwards-compatibility.
PR Close#49222
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
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 `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
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
Drops support for TypeScript 4.8 from the compiler and removes all of the compatibility code we had for it.
BREAKING CHANGE:
* TypeScript 4.8 is no longer supported.
PR Close#49155
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
This commit exposes `signal`, `computed`, `effect` and various helpers from
the `@angular/core` entrypoint.
These APIs are marked as `@developerPreview` and are still prototypes in
active development. Their final shapes will be subject to our internal
design reviews as well as one or more community RFCs. We're exporting them
now to allow for experimentation using 16.0.0 next and RC releases.
PR Close#49150
This commit checks in (but does not export) a prototype implementation of
Angular Signals, along with its unit test suite and a README explaining the
algorithms used.
Signals are not a new concept in the framework space, but there are many
different flavors of implementations. These differ radically both in terms
of public API as well as behavioral details (such as eager vs lazy
computation, batching behavior, equality, cleanup, nesting, etc).
This commit comprises a bespoke implementation that we've designed to best
meet Angular's needs, especially when it comes to compatibility and
flexibility of use within existing applications.
Many of the API features of this implementation of signals, as well as the
larger direction of reactivity in Angular, will be discussed in future RFCs.
Co-Authored-By: Pawel Kozlowski <pkozlowski.opensource@gmail.com>
PR Close#49091
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
Fixes that the `ImportManager` was returning the `propertyName` instead of the `name` when there's an import with a conflicting identifier.
PR Close#49139
While unlikely, prior to this change it was possible to provide a nested array of styles to the render. This required the framework to handle this by doing a flatten operation. This change also renames the `flattenStyles` method as it no longer flattens the styles.
BREAKING CHANGE: `RendererType2.styles` no longer accepts a nested arrays.
Closes#48317
PR Close#49072
This commit removes the NGCC code and all the related infra setup required to support it.
BREAKING CHANGE: Angular Compatibility Compiler (ngcc) has been removed and as a result Angular View Engine libraries will no longer work
PR Close#49101
Currently style of components using `encapsulation`, `None` or `Emulated` will not be removed from the DOM once the component get destroyed.
This change addresses this by keeping track of the number of times a component is rendered, when the component is destroyed the counter is decreased and once this reaches zero the style element is removed from the DOM.
Currently, this new behaviour is on opt-in bases, but it will be changed in the next major version.
To opt-in, set the `REMOVE_STYLES_ON_COMPONENT_DESTROY` DI token to `true`.
Example
```ts
@NgModule({
declarations: [
AppComponent,
],
imports: [
BrowserModule
],
providers: [
{ provide: REMOVE_STYLES_ON_COMPONENT_DESTROY, useValue: true }
],
bootstrap: [AppComponent]
})
export class AppModule { }
```
Closes#16670
PR Close#48298
Currently as a part of the bootstrapping API migration we comment out the metadata of the root module and instruct users to re-run the module pruning step which can be cumbersome. These changes run the module pruning automatically.
Note that initially I tried to reuse the module pruning logic and to run it against the existing program, but it was problematic, because it was common to have conflicting changes for the same AST nodes.
PR Close#49030
The terser update included various changes, including changes to the
inline optimizations. Constants like for the bloom filter are no longer
inlined multiple times, but instead the constant is preserved and used
with a shortened/mangled name.
Note this also applies to other symbols like `SimpleChanges` too.
This means that such new variables now show up in the symbols goldens.
Concrete examples of inlined & no-longer inlined constants can be
seen in the PR description: https://github.com/angular/angular/pull/49000#issue-1576416106
PR Close#49000
Adds a function that allows for the import resolution for files to be customized in the standalone migration. Externally it's only use is to change `NgForOf` to `NgFor`, but we'll need it internally to deduplicate some Material modules.
Fixes#49006.
PR Close#49022
Fixes that the migration was unnecessarily traversing top-level nodes. This was a large performance bottle-neck, because it involves a lot of language service lookups.
PR Close#49010
In some internal migrations the language service was throwing for some file reads which was crashing the migration. These changes add a `try/catch` to avoid interrupting it.
PR Close#49010
For the module pruning and bootstrap API migration steps we depend heavily upon the TypeScript `LanguageService` which ends up being slow on a large project. E.g. in some large internal projects single-file lookups were taking around 30s.
These changes introduce a wrapper around the `LanguageService` that we can use to trick it into not traversing the entire project every time.
PR Close#49010
We're using Node's `path` utilities to remap existing imports and create new ones which can yield paths with forward slash separators.
These changes add some logic to ensure that we only generate forward slashes.
PR Close#48993
Normally having a standalone declaration in the `imports` array is an error and something we handle in the conversion to standalone, but tests can end up in this situation, because apps may have separate tsconfigs for the main app and for tests.
These changes make it so that we move any incorrectly-defined standalone declarations, even if they aren't part of the current migration.
PR Close#48987
For the standalone migration we need to pass a couple of compiler flags which accidentally also overwrote the project's compiler options. These changes extend the options instead.
PR Close#48987
Fixes that we were copying all expressions in the `imports` array of the test to the `imports` of the component, including any potential `ModuleWithProviders`.
Fixes#48971.
PR Close#48987
The first step of the migration updates the tests of the component being migrated, however it also skips any bootstraped declarations. We get back to the these declarations when converting to the standalone bootstrapping APIs, but we weren't updating their tests.
These changes rework some of the logic so that we migrate any remaining tests as a part of the final step.
Relates to #48944.
PR Close#48987
Currently the standalone migration is set up to skip any modules that have a `bootstrap` array with at least one element. This ends up being misleading for small apps who have everything in the root module.
These changes add some logic to only skip the root component.
Fixes#48944.
PR Close#48987
v16 will have a breaking change to the way `UrlTree`s are constructed.
This change is actually a bug fix that makes `UrlTree` creation correct
in more scenarios (see #48508). However, this can affect applications that are
relying on the current incorrect behavior. This commit adds a dev mode
warning when the target of a navigation will change once #48508 is
submitted.
PR Close#48688
In #48898 the `isForwardRef` flag was added to indicate whether a reference should be wrapped in a `forwardRef`. This logic assumed that the node can't be referring to another node within the same file, however from testing it looks like that's not actually the case, because we hit the same code path when an external import to the same symbol exists already.
PR Close#48988
Fixed a typo and updated the hyphenation in a couple of words to keep consistency across schematics docs style. Assuming beginners reading docs, I also added the property called
public showGreeting = true;
This is because it is available in the examples `.HTML` `*ngIf` directive snippets without being present in the `.ts` class properties declarations. also this removes potential inference that this absence is a result of the standalone migration schematics work.
PR Close#48961
Internally we'll need to remap some imports to generate better import statements. These changes add an API that we can use to do the remapping.
PR Close#48974
Adds some logic to prefer non-Angular-internal modules when generating imports. This allows us to generate better code for some cases like the `ɵInternalFormsSharedModule` in Forms.
Also adds some logic to prefer symbols that are already in the same file.
Fixes#48942.
PR Close#48958
Fixes that the standalone migration was throwing the "Could not find any paths to migrate..." error on a per-tsconfig-basis, preventing the migration from running on any configs that might occur further down in the project.
These changes move the error to after all the configs have been checked.
PR Close#48958
Previously if the standalone migration saw a `RouterModule.forRoot` with a config object, it wouldn't migrate it. These changes add some logic that convert the config object to a set of features from the new router API.
PR Close#48935
Currently the migration is set up to assume that any elements that exist in a `declarations` array will be converted to standalone and copied into the `imports` array, however that might be incorrect for some special cases like the root component.
These changes rework the declaration merging logic so that they take all the declarations being migrated into account.
PR Close#48882
Fixes that running the standalone migration with `--defaults` was throwing an error, because all the properties were specified as required. We don't need to set them as required, because they have default values.
Fixes#48845.
PR Close#48921
Fixes that we were changing the testing modules that have no `declarations` unnecessarily, resulting in more formatting changes that users would have to clean up.
PR Close#48921