184 uses dependencySatisfies to check for a good enough version of Ember to use @cached directly from @glimmer/tracking. However dependencySatisfies is quite strict on what it expects from declared package dependencies, as it will always return false (and which case the polyfilled version will get used) when the dependency (here ember-source) is not declared explicitly as a (peer) dependency. But this is the case for a lot of addons (most of them probably), given that also the addon blueprint added that only more recently.
I wonder how we should deal with that? At least we should document that addons that have ember-cached-decorator-polyfill as a dependency should also explicitly declare a peer dependency on ember-source.
Another way to look at it is maybe making dependencySatisfies less strict (which is not related to this repo here, but still mentioning this within this context)? What it does is right, but maybe it's just too strict compared to what the ecosystem has historically been? We could maybe introduce a special case for only ember-source (as so often we check for the version of that, and also addons have traditionially always assumed it's just there without bothering to declare an explicit dependency), and do the normal package resolve and version check even without a declared dependency in this narrow case?
184 uses
dependencySatisfiesto check for a good enough version of Ember to use@cacheddirectly from@glimmer/tracking. HoweverdependencySatisfiesis quite strict on what it expects from declared package dependencies, as it will always return false (and which case the polyfilled version will get used) when the dependency (hereember-source) is not declared explicitly as a (peer) dependency. But this is the case for a lot of addons (most of them probably), given that also the addon blueprint added that only more recently.I wonder how we should deal with that? At least we should document that addons that have
ember-cached-decorator-polyfillas a dependency should also explicitly declare a peer dependency onember-source.Another way to look at it is maybe making
dependencySatisfiesless strict (which is not related to this repo here, but still mentioning this within this context)? What it does is right, but maybe it's just too strict compared to what the ecosystem has historically been? We could maybe introduce a special case for onlyember-source(as so often we check for the version of that, and also addons have traditionially always assumed it's just there without bothering to declare an explicit dependency), and do the normal package resolve and version check even without a declared dependency in this narrow case?/cc @ef4