Custom model instances’ type is not assignable to Model

[seanCodes]

Reproduction

Example: https://github.com/seanCodes/ember-data-bugs/blob/main/tests/integration/components/info-test.ts#L30
Repo: seanCodes/ember-data-bugs

Description

Custom model instances’ type is not considered to extend Model. The types of Model.eachRelationship() and Model.eachAttribute() don’t match, which seems to be caused by the user-defined model expecting stricter values for the first argument of both methods (exact attribute keys, rather than any string like the base model).

interface Context extends TestContext {
  store: CustomStore
  model: Model
}

module('Integration | Component | info', function (hooks) {
  setupRenderingTest(hooks)

  hooks.beforeEach(function (this: Context) {
    this.store = this.owner.lookup('service:store')

    // ERROR: "Type 'UserModel' is not assignable to type 'Model'."
    this.model = this.store.createRecord<UserModel>('user', {
      name: 'John Doe',
    })
  })

  // ...
}

Versions

Legend: production dependency, optional only, dev only

ember-data-bugs@0.0.0 …/ember-data-bugs

devDependencies:
ember-source 5.8.0
Legend: production dependency, optional only, dev only

ember-data-bugs@0.0.0 …/ember-data-bugs

devDependencies:
ember-cli 5.8.1
Legend: production dependency, optional only, dev only

ember-data-bugs@0.0.0 …/ember-data-bugs

devDependencies:
@ember-data/adapter 5.4.0-alpha.64
@ember-data/graph 5.4.0-alpha.64
@ember-data/json-api 5.4.0-alpha.64
@ember-data/legacy-compat 5.4.0-alpha.64
@ember-data/model 5.4.0-alpha.64
@ember-data/request 5.4.0-alpha.64
@ember-data/request-utils 5.4.0-alpha.64
@ember-data/serializer 5.4.0-alpha.64
@ember-data/store 5.4.0-alpha.64
@ember-data/tracking 5.4.0-alpha.64
ember-data 5.4.0-alpha.64

[runspired]

the reason for this is that there's basically no way to type Model usefully without a pile of lies. We either have to make all the schema methods completely useless but enable subclasses to satisfy Model, or we have to type Model to understand that its only useful as a subclass at which point if you use it directly you get a lot of never.

If you can come up with a solution that satisfies both things, all for it, but I haven't dreamt one up yet myself and am suspicious that one doesn't exist given how TS does not like subclasses to narrow signatures.