Create a new pull request by comparing changes across two branches #237
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change contains an additonal test that captures scenario of the problematic .pipe usage outside of the directive class. PR Close #57671
This change removes superflous .complete calls for the migrated outputs. PR Close #57671
In case there are no signatures (like in an bare interface method), we display the implementation information. PR Close #57622
…ation (#57672) The migration took a type from the directive handler metadata, and inserted it into a synthetic node for the new input() call. This works perfectly fine, but in some cases, I saw some `T:VAE` comments attached :exploding_head: These are from the type checker which attached synthetic comments to the exact same node. PR Close #57672
…57672) Whenever the signal input migration runs in VSCode, other inputs are marked as incompatible via the config. Best effort mode currently skips those incompatibilities and still migrates them. This is incorrect as the config intends to skip those inputs, regardless of best effort mode. PR Close #57672
…iting imports (#57672) Currently whenever we apply the import manager changes in migations, we leave the decision of multi-line or single-line to the TS printer. This works, but in practice can cause signficiant file jumps/changes if there are large imports that aren't wrapped for example, or the other way around. We should try to be minimal here and preserve the existing formatting, assuming that a multi-line import remains multi-line, while a single-line import remains single-line if it already had many items in a single line, intentionally. PR Close #57672
…ignored (#57675) Add a check to the language service that ignores specified diagnostic codes. This will be useful in g3. The codes to ignore are exposed as part of the PluginConfig. Fixes github.com/angular/vscode-ng-language-service/issues/1243 PR Close #57675
) Modules like `core/primitives` are considered private and their symbols shouldn't be exposed nor linked in the docs. PR Close #57611
…runing (#57684) Currently during the module pruning stage of the standalone migration we assume that any leftover modules which only have `imports` and `exports` can safely be removed. That can be incorrect for the cases where some parts of the app were converted to standalone outside of the migration. These changes update the logic so that such modules are replaced with the `exports` which are used within the specific component. Fixes #51420. PR Close #57684
With the framework enabling `standalone` by default (making module based an opt-in), the migration will migrate none-standalone existing components and add `standalone: false` to the decorator. PR Close #57643
The typo in the [queries document](https://angular.dev/guide/components/queries#content-queries) has been corrected: Queries never **pierce** through component boundaries. PR Close #57228
…57677) Migrations may resolve files in e.g. `blaze-out` and try to compute a path for the file that is "recognizable" across workers. E.g. in one worker, it may be the actual `.ts` file inside the source tree, while in the other, the file may be inside `blaze-out`. Tsurge currently expects project relative paths to be passed around. Those project relative paths are currently only based on the single root directory. Hence paths inside `blaze-out` would actually not be recognizable. The fix idea here is that we introduce a structure for Project files. This structure will contain two fields: - an ID of a file. This is similar to a module ID in the project. Those are resolved with respect to all root directories. This matches the conceptual virtual roots of `tsconfig#rootDirs`. The IDs can be used for matching files across workers, assuming those are executing using the same root directories, and handle the same overall project (e.g. google3). - a path relative to the primary project root. Multiple roots may be configured, but the primary project root, is the directory that contains all others. See: `tsconfig.rootDir`. This path is NOT necessarily useful for matching files between stages etc, but it's useful for writing replacements for a given file to disk. Note that those two things cannot be combind into one conceptual "project relative path" because a path relative to the most appropriate root directory cannot be used for safe replacements. E.g. consider a replacement matches a file from a root directory like `/sub/`. The path inside `/sub/` would then omit the `/sub/` and later on when writing replacements, we wouldn't know which root directory it actually was part of. Hence the concept of a "project root relative path" and the "ID". ds PR Close #57677
…raversal (#57719) Instead of traversing the same paths multiple times, we should avoid this extra work and optimize. This solves some issues in super large files with extremely complex flow graphs. E.g. large `ngOnChanges` functions in Pantheon. For an example of a flow graph where it doesn't make sense to re-visit nodes that have multiple incoming edges, see this internal screenshot: https://screenshot.googleplex.com/6ub4e5e5gbzJAvH PR Close #57719
See associated pull request for more information. PR Close #57705
This addresses a minor issue where the "See whitespace in templates" phrase was not linked to its corresponding documentation section PR Close #57718
…57711) Currently several parsing errors in the new control flow (e.g. missing `track` expression) produce errors whose span targets the entire block. This can be really noisy in the IDE where the error can span many lines in the template. These changes switch to highlighting just the start of the block. PR Close #57711
This change contains a fix that takes into account comments attached to outputs and preserves / removes those as needed. PR Close #57691
This change uses the outputToObservable utility function to convert migrated outputs to Observables. This happens only in test files as it is a common practice to use RxJS to listen to events raised by the component under test. PR Close #57691
Fixing typo: reactoring -> refactoring PR Close #57726
This commit also adds the support of handling standalone proparties assigned by variables (or via shorthand assignments). PR Close #57717
This commit marks the input, output and model APIs as stable (along with the associated APIs) and thus exits the dev preview phase for those APIs. PR Close #57804
…ctly encapsulate for a component (#57809) For component stylesheet hot module replacement scenarios, it will be necessarily to directly encapsulate a component's stylesheet in a single operation. This currently requires the consumer of the `encapsulateStyle` helper to use the internal Angular attribute values combined with a find/replace over the entire stylesheet. To avoid both of these, the helper function now has an optional second parameter which allows direct and full encapsulation of a style for a given component when the component identifier is known. PR Close #57809
See associated pull request for more information. PR Close #57821
…sconfig (#57805) Whenever the `ngc` binary is used directly to parse configurations, we should try to respect the configured file system like we do in all other places. Right now one spot where we escape the FS is for reading directories to e.g. support tsconfig#includes. This commit fixes this, implementing TypeScript's read directory method leveraging the configured FS. The approach taken here was used for a couple of months/years for Angular Material migrations and no issues were found. PR Close #57805
…chematic (#57805) Introduces a new `ng generate` schematic for migration `@Input()` declarations to signal inputs. This migration is the same that is also integrated into the VSCode extension. Note: In a follow-up the documentation for this will be improved, and a flag to report reasons on why certain inputs weren't migrated, is added. PR Close #57805
Finalizes compiler implementation of the new `hydrate` triggers by: * Reworking the logic that was depending on the `hydrateSpan` to distinguish hydrate triggers from non-hydrate triggers. * Fixing that the `hydrate when` trigger didn't have a `hydrateSpan`. * Adding an error if a parameter is passed into a `hydrate` trigger. * Add an error if other `hydrate` triggers are used with `hydrate never`. * Replacing the `prefetch` and `hydrate` flags in the template pipeline with a `modifiers` field. * Fixing an error that was being thrown when reifying `hydrate` triggers in the pipeline. * Adding quick info support for the `hydrate` keyword in the language service. * Adding some tests for the new logic. PR Close #57831
This allows us to use the inheritance checks we built for the signal input migration, inside the queries migration. PR Close #57835
See associated pull request for more information. PR Close #57842
See associated pull request for more information. PR Close #57843
…57854) Notably the inheritance checking is less complete as the one in the input migration. That is because we can't efficiently determine query fields in the analyze phase of compilation units. Unless we aggresively consider every field of decorated classes as queries and complexify the merged metadata significantly, we can't reliably check for cases where a class is incompatible for migration because it overrides a member from a class that is in a different compilation unit. This is an acceptable limitation though (maybe for now), as worst case, we would migrate the class and the other compilation unit would simply break. Not ideal, but migrations are impossible to be 100% correct in general— so not a surprise. In the future, we may find ways to identify queries more reliably in analyze phase already. e.g. if the compiler were to include this metadata in the `.d.ts`, or if we decide to simply add this to the metadata, accepting potential significant HDD increase. PR Close #57854
See associated pull request for more information. PR Close #57860
The original effect design for Angular had one "bucket" of effects, which are scheduled on the microtask queue. This approach got us pretty far, but as developers have built more complex reactive systems, we've hit the limitations of this design. This commit changes the nature of effects significantly. In particular, effects created in components have a completely new scheduling system, which executes them as a part of the change detection cycle. This results in behavior similar to that of nested effects in other reactive frameworks. The scheduling behavior here uses the "mark for traversal" flag (`HasChildViewsToRefresh`). This has really nice behavior: * if the component is dirty already, effects run following preorder hooks (ngOnInit, etc). * if the component isn't dirty, it doesn't get change detected only because of the dirty effect. This is not a breaking change, since `effect()` is in developer preview (and it remains so). As a part of this redesigned `effect()` behavior, the `allowSignalWrites` flag was removed. Effects no longer prohibit writing to signals at all. This decision was taken in response to feedback / observations of usage patterns, which showed the benefit of the restriction did not justify the DX cost. The new effect timing is not yet enabled - a future PR will flip the flag. PR Close #56501
GulajavaMinistudio
merged commit ee4aab3
into
angular-indonesia:main
4 of 5 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information