Derek Wickern

I had a similar problem with ember-data 3.13.3. In my case it was a polymorphic `type` coming back from my API as `snake_case`. Changing to `kebab-case` fixed it. I think...

Here's a quick workaround, ```js import FragmentTransform from 'ember-data-model-fragments/transforms/fragment'; import FragmentArrayTransform from 'ember-data-model-fragments/transforms/fragment-array'; FragmentTransform.reopen({ serialize(snapshot) { return this._super(snapshot?._createSnapshot?.() ?? snapshot); }, }); FragmentArrayTransform.reopen({ serialize(snapshots) { return this._super(snapshots?._createSnapshot?.() ?? snapshots); },...

There's also an issue with property change notifications for `hasDirtyAttributes` on fragment arrays, which accounts for some test failures on the master branch. I did attempt doing things the "right...

Here's a workaround, ```js import FragmentArray from 'ember-data-model-fragments/array/fragment'; FragmentArray.reopen({ createFragment(props) { const type = props?.type || this.type; const fragment = this.owner.store.createFragment(type, props); return this.pushObject(fragment); }, }); ```

I couldn't figure out how to make snapshots work. Snapshots call `get` on the record, which returns the `Fragment` instance. https://github.com/emberjs/data/blob/b16011382b2321171b18ab4d23eeea26ad1d7a7c/packages/store/addon/-private/system/snapshot.ts#L165 How can we make snapshots use the serialized fragment...

I'll see about merging master into this PR. It doesn't look too bad.

It will be tricky to support `typeKey` as a function for this use-case: https://github.com/adopted-ember-addons/ember-data-model-fragments/blob/bd9042d71f3ada648b1bc3a838db3e5b5847e80e/tests/dummy/app/models/component.js#L6-L9 https://github.com/adopted-ember-addons/ember-data-model-fragments/blob/bd9042d71f3ada648b1bc3a838db3e5b5847e80e/tests/unit/serialize_test.js#L31-L43 The ComponentOptions typeKey depends on its owner's `type` attribute. Do we initialize the owner's attributes...

I suspect the file is being detected as the "models" service under pods structure. The detection [prefers pods structure over classic](https://github.com/Turbo87/intellij-emberjs/blob/master/src/main/kotlin/com/emberjs/resolver/EmberName.kt#L42-L48) (whether or not you use the pods structure in...

I have the same problem on plugin version 2017.2.1-0 but it works fine on master branch 🤔

I did something similar in #103 to resolve module paths with the app root prefix. I wonder if `JSModuleReferenceContributor` is in play when IntelliJ searches for exports.