-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shouldn't a new addon include @glimmer/component
and @glimmer/tracking
#298
Comments
For 🤷 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 Some related prior discussions, but not a whole lot -- so opening this issue is good as we probably do need to discuss!:
For 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.
|
Did you mean |
No description provided.
The text was updated successfully, but these errors were encountered: