Resolve peers from Glint and/or ember-source

[NullVoxPopuli]

… (and ember-source would be required the moment you import anything anyway)

@glimmer/component is required by Glint
ember-source is required by nearly everything 🙃 (so this addition is more preemptive than anything)

Partially resolves #100 and #77

[simonihmig]

Looks good in general, but...

Tbh, I have more than one addon where I historically never cared about peerDeps and put just everything into deps (not ember-source of course, but @glimmer/component for example). I see that the v1 addon blueprint now also has a peer dependency on ember-source, but not for @glimmer/component, I guess because not every addon necessarily will have expose components (but most/a lot will).

Which brings up the question: should we do this here?

You did this specifically because we chose to add Glint types by default, and they rely on the presence of @glimmer/component, right? If so, we only have glint packages as devDependencies, so to satisfy the peer dependency we could just add @glimmer/component to our devDependencies as well, right?

Second, however we decide on this, I think we need better guidance for addon authors on this topic (what is a dependency, what a peer, all with examples specific to the Ember ecosystem). Especially should we decide to not declare @glimmer/component a peer by default here. People - like me 🙈 - will just think, ok, I am actually importing @glimmer/component from exposed run-time code, so I'll just add it to my dependencies.

Of course out of scope for this PR, so sorry for diverging a bit, but wanted to leave this here before I forget... Especially as we have a learning team member here among the reviewers! 😬

[NullVoxPopuli]

@glimmer/component for example
because we chose to add Glint types by default, and they rely on the presence of @glimmer/component, right?

ember-source also has declared a peer on @glimmer/component.

Without this change:

ember addon peer-test -b ../NullVoxPopuli/addon-blueprint-2/ --skip-npm --pnpm
cd peer-test
pnpm i
# ... -> 

 WARN  Issues with peer dependencies found
peer-test
├─┬ ember-source 4.10.0
│ ├── ✕ missing peer @glimmer/component@^1.1.2

This may be an incorrect thing for ember-source to do, as @glimmer/component has no behavioral benefit within ember-source, and the typed-ember folks are only using it to provide some utility types for the Signature and shape-of-a-component type stuff -- see: emberjs/ember.js@6278a8b
also cc @chriskrycho, for vis
I did a search on emberjs/ember.js, and most occurrences of @glimmer/component are in comment blocks (followed by tests)

[NullVoxPopuli]

@simonihmig now only ember-source is a peer.

you are correct that it doesn't make sense for us to include @glimmer/component as a peer by default (as many utility libraries may not care about @glimmer/component at all!)

[NullVoxPopuli]

this devDep satisfies the peer requirements from ember-source and glint (when used)

[ef4]

Because everything in ember-source doesn't really resolve normally anyway, there's not much functional reason to have the peerDep on ember-source. The main reason people are forced to add it is if they want to say dependencySatisfies('ember-source', ...).

And because package managers do confusing and painful things with peerDeps, I'm hesitant to encourage every v2 addon to add this unused-but-likely-to-break-your-monorepo peerDep right now.