ember-context
ember-context copied to clipboard
Error when using with ember-source 3.12
I'm working in a legacy app currently locked to 3.12.4 and when trying to use the component I receive the following error:
Error: Assertion Failed: Invalid component manager compatibility specified
at assert (https://localhost:4000/assets/vendor.js:55007:17)
at Object.capabilities [as _componentManagerCapabilities] (https://localhost:4000/assets/vendor.js:26485:58)
at new ContextComponentManager (https://localhost:4000/assets/vendor.js:274443:51)
at https://localhost:4000/assets/vendor.js:274530:54
at RuntimeResolver._lookupComponentDefinition (https://localhost:4000/assets/vendor.js:30080:71)
at RuntimeResolver.lookupComponentHandle (https://localhost:4000/assets/vendor.js:29822:37)
at CompileTimeLookup.lookupComponentDefinition (https://localhost:4000/assets/vendor.js:26462:28)
at LazyCompiler.resolveLayoutForTag (https://localhost:4000/assets/vendor.js:62435:29)
at https://localhost:4000/assets/vendor.js:61605:28
at Compilers.compile (https://localhost:4000/assets/vendor.js:61519:7)
I scaffolded a new app with ember-source
at 3.12.4 with the same result.
When looking at this line, it seems like in versions below 3.13 capabilities
might be undefined?
By comparison, @glimmer/component
seems to handle it using the ember-compatibility-helpers
like this.
I have a fork that implements capabilities
this way and it seems to work, but I'm unaware if there are any incompatibilities or side effects (I'm relatively new to the inner workings and deprecations of Ember).
Thanks for raising the issue!
I'm happy to accept a PR that introduces a fix for this based on ember-compatibility-helpers
, as long as we can add Ember 3.12
to our ember-try
configuration to ensure that things continue to work on that version, and the modern ones!
That would mean
- Adding an entry for
ember-3.12
similar to this one - Adding the new scenario to the CI configuration here
Oh, came here for this - the README says compat with 3.12 - but I think 3.15 might be more accurate (since the package.json says ember octane)
Yeah, the README is definitely wrong here.
I'm happy to just update the README to reflect the correct version (it's a shame that the Ember CLI generates a README by default with such an old supported version; it should really default to the oldest LTS that the ember-try
configuration generated at creation time supports) but if we can actually get Ember 3.12 working instead, that would be good with me, too!
As it turns out, my solution didn't properly handle the tracked value, so initial values were fine but updates to the provider wouldn't propagate. Pre-Octane Ember isn't exactly my specialty, though. Might just be easier to set the dependency to >=3.13 for now?