add new rule to enforce the use of providedIn flag

[wKoza]

This is recognized as best practice for providers with Angular 6 (we can now perform tree shaking and remove services that aren't used by your app

[rafaelss95]

Related to #135. Btw, any news on integrate material2#validateDecoratorsRule here?

[mgechev]

Following the feature request process that lodash has, I'm closing the issue and adding votes needed label.

Later we can prioritize the feature requests by popularity and include them in a future release.

[mohammedzamakhan]

You can assign it to me

[mgechev]

GitHub does not allow this but since you're taking it I'll drop votes needed.

[rafaelss95]

@mgechev @wKoza
Currently we have the following rules to (dis)allow decorator properties values:

List of rules
no-host-metadata-property
no-inputs-metadata-property
no-outputs-metadata-property
no-queries-metadata-property
no-pipe-impure
prefer-on-push-component-change-detection
use-component-selector
use-component-view-encapsulation

... and this list is growing...

What's your opinion about implement something like material2#validateDecoratorsRule (it was already mentioned in this and other issues like #135)?

A default config would be:

{
  "rules": {
    "validate-decorators": [
      true, {
        "Component": {
          "changeDetection": "\\.OnPush$",
          "!encapsulation": "\\.None$",
          "!host": ".*",
          "!inputs": ".*",
          "!outputs": ".*",
          "!queries": ".*",
          "selector": ".*"
        },
        "Directive": {
          "selector": ".*"
        },
        "Pipe": {
          "!pure": ".*"
        }
      }
    ]
  }
}

... and of course we could allow users to customize it according to their project standards, and why not also their decorators.

[mgechev]

Sounds good. I can talk to @jelbourn to converge both rules.

[jscharett]

Does this rule allow for a non-singleton services? I haven't seen an example where provideIn is used for a component, only root/Modules.