Shouldn't a new addon include @glimmer/component and @glimmer/tracking

[kiwiupover]

No description provided.

[NullVoxPopuli]

For @glimmer/component:

🤷 I'm a fan of progressive disclosure, and -- in an ideal world -- we'd have generators modify your (peer)dependencies for you as you generate things that require known dependencies -- for example ember g component would add @glimmer/component.

Some related prior discussions, but not a whole lot -- so opening this issue is good as we probably do need to discuss!:

• Resolve peers from Glint and/or ember-source #101
• Incorrect peer setup (revealed with pnpm, npm8) #100 (glimmer stuff ends up required with --typescript) -- but see also Provide workarounds for both TS (bad peer-provided types handling) and Glint (mishandling of extensions) issues #292 -- unblocked by: [ENHANCEMENT] Use the official types in the blueprints ember-cli/ember-cli#10506

For @glimmer/tracking:

I am currently thinking about deps as add only what you need to as you need them -- because defaults tend to not be touched, and if someone uses the addon-blueprint for non-ember stuff (which they can today -- the library generated by this blueprint is kinda framework agnostic atm).

This is, of course, a tradeoff -- personally, I'd love for everyone to be thoughtful of what dependencies they're including in their library - and omitting runtime deps by default forces that thinking -- with the downside that if anyone isn't writing super generic libraries, they may always have to add the same dependencies.

For this reason, I'd like "someone" to explore an ergonomic blueprint configuration / layering system -- or maybe we iterate on what we have already idk.
I could see something like a ~/.npmrc, but for project generator, e.g.;

# ~/.blueprintrc.yaml
- in: ~/Development/emberjs/
  for:
    type: library
    dependencies:
      add:
        - @glimmer/component
        - @glimmer/tracking
      remove: 
        - stylelint # for example