[CHORE]: Eliminate default injections in favor of re-export

[snewcomer]

• eliminate explicit registration
• re-export

@runspired Do we also need this?

ref #6166

[runspired]

@runspired Do we also need this?

yes but for the adapter package

[Gaurav0]

Is there an RFC for this or is it mentioned in another RFC?

I think we need to deprecate access to the explicit registration but keep explicit registration working until 4.0, there are many applications that depend on it.

[runspired]

@Gaurav0

I think we need to deprecate access to the explicit registration but keep explicit registration working until 4.0, there are many applications that depend on it.

Registration of these is an intimate API at most. We'll do the same thing here we did for the deprecation of the explicit serializer registration and target 3.17 removal https://github.com/emberjs/data/blob/master/packages/store/addon/-private/system/core-store.ts#L3314

[runspired]

There is no current -rest or -default adapter (-rest did exist recently but was never accessible in userland so we were able to drop is already). We shouldn't add them back nor auto-register them.

[rwjblue]

FWIW, I was confused by the title here. When I saw "default injections" I thought that this was talking about the default injection of this.store in routes / controllers / etc. After reviewing this is about removing default registrations (not injections), and relying on the resolver to find these objects instead. I figured I'd comment here just in case others were equally confused (and don't take the time to review the diff).

Overall 👍👍 from me on this change...

[runspired]

@rwjblue agree, but the naming is my fault I worded it this way in the project-trim task list. I have a bad habit of using registration and injection interchangeably due to how most of the time in initializers we were calling "inject" :(

[rwjblue]

Oh, ya, no worries here at all, I was just confused until I read the diff (which looks great).