Use the types published from Ember itself; require Ember.js v4.8.4 or above

[chriskrycho]

• Specify a peerDependencies requirement of Ember 4.8.
• Drop the corresponding @types packages.

[simonihmig]

Sorry for hijacking this older PR for a new discussion, but I was just trying to figure out if upgrading to the new major version in another addon (cc @NullVoxPopuli) can be done without a breaking change there. And also I wanted to see how addons can consume the new native types while supporting older Ember versions...

So, the Readme states that Ember 3.28 is still supported. While this change suggests otherwise. You could argue that it is supported but not tested, in which case I would argue anything that is not tested is not supported! So what is true? 😏

Unrelated to this specific project, is there any other way addons can start to consume the preview types, while still having test coverage for older Ember versions that do not have them? I guess we could make ember-try add all those @types packages, but then import 'ember-source/types' is likely to break, right?

[chriskrycho]

Just saw this as I was clearing out my inbox! There are two things to note here—in order of importance:

1. The only way to test that kind of interop correctly is to have two CI passes with their own dependencies. The cleanest/easiest way to do that is with two separate test apps which just have their own dependencies, but you could also imagine doing it by specifying a list of dependencies to install and doing a yarn add -D <that list of deps> in separate CI runs. The key is that they need some degree of isolation from each other so they don’t stomp on each other.

2. It actually turns out that you don’t have to worry about the side-effect imports: import 'ember-source/types'; is actually always allowed as long as ember-source exists. Yes, this is a footgun: it will totally silently fail if that is not present, with the surfacing symptom being type checking errors about not finding @ember/<whatever> if the types are not there. That means that you could have a single test app that covers both… but that would be pretty unclear, so I would not recommend it. 😂

As for compatibility with native types for this add-on in particular without coupling it to a breaking change, it is likely possible in principle by taking advantage of (1), so I'd be happy to merge PRs that supported it for versions as far back as 0.5.x.