Skip to content

refactor: hammer migration should add "HammerModule" if needed #17444

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

devversion
Copy link
Member

The v9 HammerJS migration should add the HammerModule to the
app module if needed.

Additionally if HammerJS is not used in templates (or in general),
we remove references to the "HammerModule". This scenario can happen
if someone updates to v9 Angular while keeping Angular Material v8. In
that case, the author will add the HammerModule to the app module and
whenever the update to v9+ Angular Material is performed, the HammerModule
is not needed anymore.. so we can remove it automatically.

The v9 HammerJS migration should add the `HammerModule` to the
app module if needed.

Additionally if HammerJS is not used in templates (or in general),
we remove references to the "HammerModule". This scenario can happen
if someone updates to v9 Angular while keeping Angular Material v8. In
that case, the author will add the `HammerModule` to the app module and
whenever the update to v9+ Angular Material is performed, the `HammerModule`
is not needed anymore.. so we can remove it automatically.
@devversion devversion requested a review from jelbourn as a code owner October 18, 2019 11:04
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Oct 18, 2019
@devversion devversion added pr: merge safe target: major This PR is targeted for the next major release labels Oct 18, 2019
@@ -235,6 +250,45 @@ export class HammerGesturesRule extends MigrationRule<null> {
});
}

/** Removes all references to the "HammerModule" from "@angular/platform-browser". */
private _removeHammerModuleReferences() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jelbourn As I've shortly explained in the PR description, it will be a rare scenario that we need to remove the HammerModule, unless you can think of a different scenario?

if you think we should just not handle this case, I'm good with it. otherwise, it will be just that function that handles that scenario.

@devversion devversion added the P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful label Oct 18, 2019
@devversion devversion added this to the 9.0.0 milestone Oct 18, 2019
Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Oct 18, 2019
@mmalerba mmalerba merged commit 2f197cd into angular:master Oct 18, 2019
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Nov 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants