forbid overriding builtin services

[NullVoxPopuli]

do folks want this? should I keep working on it?

I think it could be useful, because things only go wrong when people override the router service

[bmish]

We could call this no-overriding-builtin-services? I would include router and store (Ember Data) for sure. Are there any other builtin services we should include?

I don't think this rule needs to be configurable, since people can use the existing no-restricted-service-injections rule if they want customization.

UPDATE: see other comment thread for more discussion.

[bmish]

Is owner.register('service:foo') ever used outside tests? I thought it was mostly for tests but I could be wrong. If it's just for tests, do we care about it?

[NullVoxPopuli]

it technically could happen -- I imagine the behavior would mostly be undefined

[NullVoxPopuli]

I know the speed of certain rules is important, and only looking at test files is a perf improvement we can make.

Maybe it's rare enough where we don't need to worry about app/addon trees?
I'm going to check ember-observer.

In any case, I do still want to prevent this:

let owner = this.owner;

owner.register('...');

this addon will need to keep track of all the ways people can get and manipulate the owner reference

[NullVoxPopuli]

the search: https://emberobserver.com/code-search?codeQuery=owner.register

[NullVoxPopuli]

a bit more precise: only 12 usages: https://emberobserver.com/code-search?codeQuery=owner%5C.register%5C((%27%7C%22)service&fileFilter=addon&regex=true&sort=usages&sortAscending=false
all seem to be addon-test-support, which is fine -- so we can scope to tests. woohoo!

now, looking at the what we actually want to prevent:
https://emberobserver.com/code-search?codeQuery=owner%5C.register%5C((%27%7C%22)service%3Arouter&fileFilter=tests&regex=true&sort=usages&sortAscending=false

only 21 usages -- less than what I've seen internally 🙃
if only I could check app code with ember observer

[NullVoxPopuli]

the router is the only one I've ran in to. I don't use ember-data regularly enough to know if the store would cause problems 🤷

[bmish]

Okay. So this doesn't seem super useful to me personally but if you feel strongly that it's useful and likely to help people, feel free to proceed.

If you want to proceed, the path forward that I'm leaning towards is:

1. Create no-router-service-registration that could eventually be enabled as recommended. Limited to just the router service since it's unclear if any other services have a problem with this. If you determine this is likely to apply to other built-in services, then it could be named no-built-in-service-registrations.
2. If people actually wanted restrict arbitrary service registrations, someone could create an optional no-restricted-service-registrations rule at a later point. Still, I'm unclear that this is actually needed.

[NullVoxPopuli]

as a library author, i think optionally preventing registration of similar services is important.

i lean towards "no-restricted-service-registrations" with router as default

[NullVoxPopuli]

(i'd use that a bunch internally)

[bmish]

i lean towards "no-restricted-service-registrations" with router as default

Okay, I'm open to considering that.

I am just a bit worried about that option as there are many other no-restricted-* rules that are typically intended as purely optional (not recommended) rules which don't restrict anything by default but can be configured to restrict things as desired:

• no-restricted-imports
• no-restricted-syntax
• ember/no-restricted-service-injections
• ember/no-restricted-property-modifications
• ember/no-restricted-invocations

So it may be confusing to people that this new no-restricted-service-registrations rule restricts router by default.