4.13 Canary | Regression Tracking

[runspired]

WONTFIX

• transforms now come from a public instead of private import location
• setConfig may be required?
• extending @ember-data/store instead of ember-data/store now requires full configuration
• super in hooks in classes extending @ember-data/store no longer works
• model._notifyProperties has been removed
• cache is stricter:
  • You must include an 'id' for the resource data ${resource.type}
  • Missing Resource Type: received resource data with a type '${resource.type}' but no schema could be found with that name.

MAYBEFIX

• adapter.useFetch is assigned in a new way, resulting in the getter approach in app adapters not working. fields approach works e.g. useFetch = false.
• isRelationship and isAttribute on field meta is no longer present. These were meant to be private and not part of the spec, but some apps may have discovered and made use of them.
• relationship graph uses the passed in arrays from operations that update remote state for perf, this exposes them to accidental mutation later. We should consider freezing and/or slicing these arrays in debug as this is mostly an issue with tests using mirage.
  • This can result in Relationship state sometimes storing non-stable identifiers
• hasMany relationships will notify any time they receive an updated payload even if the state is exactly the same due to the fix in # for ensuring we notify for potential re-ordering. (feb6e5a#diff-6bf06ca7b029990de472c9fae36ea1e7e074b8e3d8ddfaf87edc2b5eb41e5d76R154)
• existing notification bug where we will notify attribute keys that aren't in the schema (e.g. due to the API returning keys that aren't in the schema which is really common in Mirage) can lead to over-notification issues now that we subscribe to these notifications in the Request component.

TO FIX

• deprecated registerSchema does not setup schema in a way that avoids the store attempting to call createSchemaService
• getSchemaDefinitionService only checks for schemas registered with registerSchema
• receiving a new request with the same id as the original request in the request component can error because the second request will be backgrounded and we don't account for that in the request validation. Error is The `request` passed to `RequestManager.request(<request>)` was empty (`{}`). Requests need at least one valid key.
• ember-inflector support initializer needs to be backported

[nickschot]

Trying out 4.13-alpha.4 (upgraded from latest 4.12) I ran into what appears to be an inflection issue.

Did anything change in that area, or am I missing something else?

Model definition with @belongsTo('media', { inverse: null, async: true }) media; with a model named media.js now throws Error: No model was found for 'medium' and no schema handles the type at runtime.

It's set up with the inflector as: Inflector.inflector.uncountable('media', 'media');

[runspired]

@nickschot great find! in 5.x we deprecated support for ember-inflector. 5.x deprecations are activateable in 4.13 but off-by-design since they would be new deprecations.

To manage that deprecation, we automatically intercept inflections from ember-inflector and add them to our own inflection library.

That interception logic in ember-data may not be setup right in 4.13, or you may be assembling the packages yourself (as opposed to using ember-data) in which case the interception needs to be explicitly installed in your app. I'll look into the former.

Sidenote: the check if (macroCondition(dependencySatisfies('ember-inflector', '*'))) { will fail if ember-inflector is not installed by your app as a direct dependency iirc.

[nickschot]

Some quick answers to that & a bit more context:

• ember-inflector was already a direct devdep of the app
• we use ember-data and extend the store from ember-data/store, but I did have to install @ember-data/store and @warp-drive/build-config for it to build/boot. There is a bit of customisation of the store service, but it does call super etc.
• @embroider/macros is also a direct dep
• I tried to check if the macroConditions in request-utils/deprecation-support even run, but I don't see them triggered. I noticed in current ember-data that's imported here: https://github.com/emberjs/data/blob/main/packages/-ember-data/app/initializers/ember-data.js#L1 while something like that doesn't appear to be present in 4.13 https://github.com/emberjs/data/blob/v4-main/packages/-ember-data/app/initializers/ember-data.js (I don't know the depth of the other imports there, but it might be a hint).
• the app doesn't use Embroider, latest auto-import is present.

EDIT:

• After manually importing deprecation-support in an initializer it seems to work, so looks like it might just be that import missing somewhere.

[runspired]

Thanks! I'll get that initializer backported :)

[gitKrystan]

@nickschot Can you try the latest 4.13 canary? It should have the initializer fix.

[nickschot]

@nickschot Can you try the latest 4.13 canary? It should have the initializer fix.

Most of our test suite seems to pass on CI, but the initializer fix doesn't seem to work when running tests through localhost:4200/tests.

I also had to make sure to have all the proper @ember-data & @warp-drive packages available in the top level node_modules (did a quick fix with a public hoist for testing).

There's also some other issues, but I have to dig into those more to see if that's just caused by the test setup.

[runspired]

the initializer fix doesn't seem to work when running tests

via any mechanism or just when launching that way?

available in the top level node_modules

because typescript? or because you build with embroider which disallows the transitive dependency and thus things like import Model from '@ember-data/model'; don't "just work" anymore?

[nickschot]

the initializer fix doesn't seem to work when running tests

via any mechanism or just when launching that way?

available in the top level node_modules

because typescript? or because you build with embroider which disallows the transitive dependency and thus things like import Model from '@ember-data/model'; don't "just work" anymore?

As discussed in chat: breaks on visiting /tests but works on CI with prebuilt app (environment=test) + ember-exam

In addition @warp-drive/build-config currently needs to be hoisted/added to deps. From chat:

TLDR we need to ensure app re-exports are exported out of library code so that build config is processed correctly