Export Utils to Allow Better Lint Extension of Common Ember Patterns

[rtablada]

When working on custom patterns for teams, it is pretty common to need to do things like deprecate a service method/property or some other Ember pattern specific feature.

The utils in this project are really useful, but currently are not exported in anyway so teams have to recreate them on their own.

Note

An alternative to exporting these utilities would be to make this project a monorepo/workspace and publish a helpers/utils package explicitly. IMO this is actually a better experience so that users could use things like getImportIdentifier without tying directly to Ember.

[bmish]

Note that we actually do export Ember-specific utils here:

• https://github.com/ember-cli/eslint-plugin-ember/blob/18a1715775b1e60532e45d61a98fd1e4d27cde75/lib/index.js##L14-L16

We previously exported the general utils too, but stopped doing so here:

• #1513

The idea behind why we export Ember utils and not other generic utils is that the Ember utils are related to the purpose of this package (Ember linting) whereas the generic utils aren't. And exporting random utils increases the API surface of this package that we have to maintain, and simple changes to these utils that are mostly intended for internal usage become breaking changes.

What utils do you need and can you give us some context on what they are needed for? That would help us determine, on an individual basis, if it makes sense for us to host them or if we need to find a better home for them. I would love if there were more third-party packages that hosted useful eslint utils, but I haven't found many.

[rtablada]

@bmish most of the helpers that I've had to reproduce are around:

1. imports
2. decorators
3. https://github.com/ember-cli/eslint-plugin-ember/blob/master/lib/utils/scope-references-this.js

We have limited use for isEmberRoute or isInjectedServiceProp and haven't really needed to grab any of the other utils.