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.12similar 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?