Robert Jackson

> We do want to go ahead and just add ember-modifier to the default blueprint. Hmm, this seems somewhat strange to me (and I missed the core team meeting referenced)....

> How is this different from (a) adding a @glimmer/modifier which is in the default blueprint I agree, I don't think it is fundamentally different (other than the current design...

@SergeAstapov > This RFC seeks to fill this gap in Ember.js' development mental model by providing ember-modifier in the blueprint. ember-modifier will be added to devDependencies of both app and...

@chriskrycho > Wouldn’t it make more sense (both from an ease-of-implementation POV and an ease-of-figuring-it-out-to-maintain-it POV) to just leave it as a blueprint supplied by ember-modifier? I definitely agree that...

Oh, also, FWIW I think what I'm saying in https://github.com/emberjs/rfcs/pull/811#issuecomment-1124007886 really ought to apply to `@glimmer/component` as well. Without some mechanism for knowing which version of `ember-modifier` (or `@glimmer/component`) a...

@chriskrycho > Why could we as a community not absorb changes there? I'm asking because, assuming Embroider v2 addon format versions of these packages, it seems to me that the...

> For me it seems to deserve its own RFC. Totally agree! > Let me propose the following: > > * Create a RFC how dependencies like these (@glimmer/component, @glimmer/tracking,...

> Not sure I get what you mean here. Who is "folks"? Like I would see user-land code to only use ESM, and eventually @embroider/macros (like importSync()) for the special...

FWIW, the thing you want is possible if you drop down a level and use the primitive caching API. Given that `@cached` is _basically_ going to end up being implemented...

I vaguely think I would prefer an implementation that didn't rely on mutating the object, something like: ```js @cached get bidSources() { const _prevs = getCachedValue(this, 'bidSource') || []; const...