🤷 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!:
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
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 componentwould 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!:
--typescript) -- but see also https://github.com/embroider-build/addon-blueprint/pull/292 -- unblocked by: https://github.com/ember-cli/ember-cli/pull/10506For
@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.;