Create migration (or not) for the opt-in HammerModule in NG9

[ChronosSF]

Description

With Angular 9 components such as the igxSlider won't work in user apps unless the HammerModule is imported on root level.

To prevent users from encountering issues with our Hammer-dependant components we have 3 options (ordered by complexity):

• create smart migration that imports HammerModule if we detect the usage of a hammer-dependant component - very complicated - check this similar migration by material
• create a simpler migration that always adds the module or prompts the user to decide if he wants it
• just add it as a breaking change in the Changelog

(or we can always get rid of our hammer dependency :) )

• igniteui-angular version: 9.0.0
• browser: n/a

Steps to reproduce

1. Create a new ng9 app and add an igxSlider
2. Try to drag the slider

Result

Dragging doesn't work until you include the HammerModule from @angular/platform-browser in the app root module.

[damyanpetev]

As much as I like the smart import - indeed it might be a bit of a stretch. And we'll need start describing which components need the HammerModule. Actually, we might need to start doing that anyway for both user documentation and meta info for tooling.

Considering we already include the hammer script on project setup (ng add or Ignite UI CLi project) seems kind of a miss to not import the module as well. I guess it can be prompt-y, though don't remember if I've seen migrations with prompts.

[kdinev]

If certain modules cannot function without hammer, then hammer should be made a dependency.

[damyanpetev]

@kdinev Not an option unfortunately.. Must be imported at root (see https://github.com/angular/angular/pull/32203) since it adds an event plugin and those are only loaded once for the platform. It's basically like BrowserAnimationsModule.