Audit peerDependencies

[gilest]

Pulled out of #894 where devDependencies have been added to @babel/runtime and @ember/string.

As suggested by @jelhan

... may need to go into peerDependency to avoid a deprecation in Ember 4.10+. Adding as peer dependency would be a breaking change. Maybe better done in separate PR.

When doing a new major for that, we should also revisit other dependencies and see if they should be peer dependencies instead. E.g. @glimmer/tracking and @glimmer/component.

[jelhan]

My comment was only meant for @ember/string. I don't know enough about @babel/runtime to understand how that one should be handled.

[jelhan]

I'm not an expert on that topic but we should investigate if the following dependencies and dev dependencies should go into peer dependencies:

• @ember/string
• @ember/test-helpers
• @ember/test-waiters
• @glimmer/component
• @glimmer/tracking
• ember-modifier
• ember-source
• tracked-built-ins

Most of them are already part of the apps blueprint. For ember-modifier and tracked-built-ins RFCs exists to add them.

[gilest]

Regarding the ember-cli-babel v8 upgrade notes:

Upgrade Path for Addons
Since (v1) addons bring in their own version of ember-cli-babel, they should now also bring in their own version of @babel/core. This means that, addons should add @babel/core under dependencies in their package.json file. This makes the dependency on @babel/core more explicit while also avoiding addons having to cut a breaking release to update ember-cli-babel to v8.

@bertdeblock can we safely ignore this in a v2 addon?

[bertdeblock]

Indeed, v2 addons don't use ember-cli-babel if I'm not mistaken, so those notes are only relevant for v1 addons.