fix(core): renderer-to-renderer2 migration not migrating methods #33571
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
devversion
added
area: core
crisbeto
reviewed
Nov 4, 2019
| return ` | ||
| import '@angular/core'; | ||
| declare module "@angular/core" { | ||
| class Renderer {} |
There was a problem hiding this comment.
We aren't compiling the code so maybe it doesn't matter, but wouldn't this technically cause compilation errors for something like someInstance.setElementClass since the Renderer class is empty? Could we do declare const Renderer: any instead or would that also break type checking?
There was a problem hiding this comment.
Yeah it would cause errors, but since we don't collect diagnostics, the error won't be reported. It shouldn't have an effect on the migration either.
I think switching to any will break since the type checker will then return any if we call getTypeAtLocation.
kara
removed
the
action: review
kara
added
action: cleanup
The `renderer-to-renderer2` migration currently does not work properly in v9 because the migration relies on the type checker for detecting references to `Renderer` from `@angular/core`. This is contradictory since the `Renderer` is no longer exported in v9 `@angular/core`. In order to make sure that the migration still works in v9, and that we can rely on the type checker for the best possible detection, we take advantage of module augmentation and in-memory add the `Renderer` export to the `@angular/core` module.
devversion
force-pushed
the
fix/core-migration-renderer2-v9
branch
from
4d4d711
to
7fd552d
Compare
This comment has been minimized.
This comment has been minimized.
devversion
added
the
merge: caretaker note
|
Caretaker: Failure for |
|
Presubmit failures are also unrelated. Still need to investigate the integration_test failures |
atscott
pushed a commit
that referenced
this pull request
Nov 5, 2019
) The `renderer-to-renderer2` migration currently does not work properly in v9 because the migration relies on the type checker for detecting references to `Renderer` from `@angular/core`. This is contradictory since the `Renderer` is no longer exported in v9 `@angular/core`. In order to make sure that the migration still works in v9, and that we can rely on the type checker for the best possible detection, we take advantage of module augmentation and in-memory add the `Renderer` export to the `@angular/core` module. PR Close #33571
mohaxspb
pushed a commit
to mohaxspb/angular
that referenced
this pull request
Nov 7, 2019
…ular#33571) The `renderer-to-renderer2` migration currently does not work properly in v9 because the migration relies on the type checker for detecting references to `Renderer` from `@angular/core`. This is contradictory since the `Renderer` is no longer exported in v9 `@angular/core`. In order to make sure that the migration still works in v9, and that we can rely on the type checker for the best possible detection, we take advantage of module augmentation and in-memory add the `Renderer` export to the `@angular/core` module. PR Close angular#33571
mohaxspb
pushed a commit
to mohaxspb/angular
that referenced
this pull request
Nov 7, 2019
…ular#33571) The `renderer-to-renderer2` migration currently does not work properly in v9 because the migration relies on the type checker for detecting references to `Renderer` from `@angular/core`. This is contradictory since the `Renderer` is no longer exported in v9 `@angular/core`. In order to make sure that the migration still works in v9, and that we can rely on the type checker for the best possible detection, we take advantage of module augmentation and in-memory add the `Renderer` export to the `@angular/core` module. PR Close angular#33571
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The
renderer-to-renderer2migration currently does not workproperly in v9 because the migration relies on the type checker
for detecting references to
Rendererfrom@angular/core.This is contradictory since the
Rendereris no longerexported in v9
@angular/core. In order to make sure thatthe migration still works in v9, and that we can rely on the
type checker for the best possible detection, we take advantage
of module augmentation and in-memory add the
Rendererexportto the
@angular/coremodule.Before coming up with the augmentation solution, I spent quite some time re-working the
detection to be not based on the
ts.TypeChecker. Though, I went with this solution as it gives usthe best detection of the
Rendererand doesn't involve reworking the whole detection.