@warp-drive-mirror/build-config 5.6.0-alpha.3 → 5.6.0-alpha.5

package/unstable-preview-types/debugging.d.ts

@@ -1,9 +1,6 @@
 declare module '@warp-drive-mirror/build-config/debugging' {
   /**
-    @module @warp-drive-mirror/build-config
-   */
-  /**
-   * ## Debug Logging
+   * # Log Instrumentation <Badge type="tip" text="debug only" />
    *
    * Many portions of the internals are helpfully instrumented with logging.
    * This instrumentation is always removed from production builds.
@@ -15,19 +12,11 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    * either in your build config or via the runtime helper.
    *
    *
-   * ### Activation Via Runtime Helper
-   *
-   * A runtime helper is attached to `globalThis` to enable activation of the logs
-   * from anywhere in your application including from the devtools panel.
-   *
-   * The runtime helper overrides any build config settings for the given flag
-   * for the current browser tab. It stores the configuration you give it in
-   * `sessionStorage` so that it persists across page reloads of the current tab,
-   * but not across browser tabs or windows. Thus if you need to deactivate the
-   * logging, you can call the helper again with the same flag set to `false` or
-   * just open a new tab/window.
+   * ## Runtime Activation
    *
-   * Example Usage:
+   * ::: tip 💡 Just Works in browser Dev Tools!
+   * No import is needed, and the logging config is preserved when the page is refreshed
+   * :::
    *
    * ```ts
    * setWarpDriveLogging({
@@ -36,26 +25,34 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    * })
    * ```
    *
-   * ### Activation Via Build Config
+   * A runtime helper is attached to `globalThis` to enable activation of the logs
+   * from anywhere in your application including from the devtools panel.
+   *
+   * The runtime helper overrides any build config settings for the given flag
+   * for the current browser tab. It stores the configuration you give it in
+   * `sessionStorage` so that it persists across page reloads of the current tab,
+   * but not across browser tabs or windows.
+   *
+   * If you need to deactivate the logging, you can call the helper again with the
+   * same flag set to `false` or just open a new tab/window.
+   *
+   * ## Buildtime Activation
    *
    * ```ts
    * setConfig(__dirname, app, {
    *   debug: {
-   *     LOG_CACHE: false, // data store received to update cache with
-   *     LOG_NOTIFICATIONS: false,
+   *     LOG_CACHE: true,
    *     LOG_REQUESTS: false,
-   *     LOG_REQUEST_STATUS: false,
-   *     LOG_IDENTIFIERS: false,
-   *     LOG_GRAPH: false,
-   *     LOG_INSTANCE_CACHE: false,
-   *     LOG_METRIC_COUNTS: false,
-   *     DEBUG_RELATIONSHIP_NOTIFICATIONS: false,
+   *     LOG_NOTIFICATIONS: true,
    *   }
    * });
    * ```
    *
-   * @class DebugLogging
-   * @public
+   * The build config settings are used to set the default values for the
+   * logging flags. Any logging flag that is not set in the build config
+   * will default to `false`.
+   *
+   * @module
    */
   /**
    * log cache updates for both local
@@ -66,32 +63,58 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    *
    * The others were `LOG_OPERATIONS` and `LOG_MUTATIONS`.
    *
-   * @property LOG_CACHE
-   * @type {Boolean}
    * @public
+   * @since 5.5
    */
   export const LOG_CACHE: boolean;
+  /**
+   * <Badge type="danger" text="removed" />
+   *
+   * This flag no longer has any effect.
+   *
+   * Use {@link LOG_CACHE} instead.
+   *
+   * @deprecated removed in version 5.5
+   * @public
+   */
+  export const LOG_PAYLOADS: boolean;
+  /**
+   * <Badge type="danger" text="removed" />
+   *
+   * This flag no longer has any effect.
+   *
+   * Use {@link LOG_CACHE} instead.
+   *
+   * @deprecated removed in version 5.5
+   * @public
+   */
+  export const LOG_OPERATIONS: boolean;
+  /**
+   * <Badge type="danger" text="removed" />
+   *
+   * This flag no longer has any effect.
+   *
+   * Use {@link LOG_CACHE} instead.
+   *
+   * @deprecated removed in version 5.5
+   * @public
+   */
+  export const LOG_MUTATIONS: boolean;
   /**
    * Log decisions made by the Basic CachePolicy
    *
-   * @property LOG_CACHE_POLICY
-   * @type {Boolean}
    * @public
    */
   export const LOG_CACHE_POLICY: boolean;
   /**
    * log notifications received by the NotificationManager
    *
-   * @property LOG_NOTIFICATIONS
-   * @type {Boolean}
    * @public
    */
   export const LOG_NOTIFICATIONS: boolean;
   /**
    * log requests issued by the RequestManager
    *
-   * @property LOG_REQUESTS
-   * @type {Boolean}
    * @public
    */
   export const LOG_REQUESTS: boolean;
@@ -99,8 +122,6 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    * log updates to requests the store has issued to
    * the network (adapter) to fulfill.
    *
-   * @property LOG_REQUEST_STATUS
-   * @type {Boolean}
    * @public
    */
   export const LOG_REQUEST_STATUS: boolean;
@@ -108,8 +129,6 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    * log peek, generation and updates to
    * Record Identifiers.
    *
-   * @property LOG_IDENTIFIERS
-   * @type {Boolean}
   
    * @public
    */
@@ -117,8 +136,6 @@ declare module '@warp-drive-mirror/build-config/debugging' {
   /**
    * log updates received by the graph (relationship pointer storage)
    *
-   * @property LOG_GRAPH
-   * @type {Boolean}
    * @public
    */
   export const LOG_GRAPH: boolean;
@@ -126,8 +143,6 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    * log creation/removal of RecordData and Record
    * instances.
    *
-   * @property LOG_INSTANCE_CACHE
-   * @type {Boolean}
    * @public
    */
   export const LOG_INSTANCE_CACHE: boolean;
@@ -135,8 +150,6 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    * Log key count metrics, useful for performance
    * debugging.
    *
-   * @property LOG_METRIC_COUNTS
-   * @type {Boolean}
    * @public
    */
   export const LOG_METRIC_COUNTS: boolean;
@@ -144,8 +157,6 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    * Helps when debugging causes of a change notification
    * when processing an update to a hasMany relationship.
    *
-   * @property DEBUG_RELATIONSHIP_NOTIFICATIONS
-   * @type {Boolean}
    * @public
    */
   export const DEBUG_RELATIONSHIP_NOTIFICATIONS: boolean;
@@ -157,7 +168,7 @@ declare module '@warp-drive-mirror/build-config/debugging' {
    *
    * LOG_METRIC_COUNTS must also be enabled.
    *
-   * @typedoc
+   * @internal
    */
   export const __INTERNAL_LOG_NATIVE_MAP_SET_COUNTS: boolean;
 }

package/unstable-preview-types/debugging.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"debugging.d.ts","sourceRoot":"","sources":["../src/debugging.ts"],"names":[],"mappings":"AAAA;;GAEG;AACH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,SAAS,EAAE,OAAe,CAAC;AACxC;;;;;;GAMG;AACH,eAAO,MAAM,gBAAgB,EAAE,OAAe,CAAC;AAE/C;;;;;;GAMG;AACH,eAAO,MAAM,iBAAiB,EAAE,OAAe,CAAC;AAChD;;;;;;GAMG;AACH,eAAO,MAAM,YAAY,EAAE,OAAe,CAAC;AAC3C;;;;;;;GAOG;AACH,eAAO,MAAM,kBAAkB,EAAE,OAAe,CAAC;AACjD;;;;;;;;GAQG;AACH,eAAO,MAAM,eAAe,EAAE,OAAe,CAAC;AAC9C;;;;;;GAMG;AACH,eAAO,MAAM,SAAS,EAAE,OAAe,CAAC;AACxC;;;;;;;GAOG;AACH,eAAO,MAAM,kBAAkB,EAAE,OAAe,CAAC;AACjD;;;;;;;GAOG;AACH,eAAO,MAAM,iBAAiB,EAAE,OAAe,CAAC;AAChD;;;;;;;GAOG;AACH,eAAO,MAAM,gCAAgC,EAAE,OAAe,CAAC;AAE/D;;;;;;;;;GASG;AACH,eAAO,MAAM,oCAAoC,EAAE,OAAe,CAAC"}
+{"version":3,"file":"debugging.d.ts","sourceRoot":"","sources":["../src/debugging.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,SAAS,EAAE,OAAe,CAAC;AAExC;;;;;;;;;GASG;AACH,eAAO,MAAM,YAAY,EAAE,OAAe,CAAC;AAE3C;;;;;;;;;GASG;AACH,eAAO,MAAM,cAAc,EAAE,OAAe,CAAC;AAE7C;;;;;;;;;GASG;AACH,eAAO,MAAM,aAAa,EAAE,OAAe,CAAC;AAE5C;;;;GAIG;AACH,eAAO,MAAM,gBAAgB,EAAE,OAAe,CAAC;AAE/C;;;;GAIG;AACH,eAAO,MAAM,iBAAiB,EAAE,OAAe,CAAC;AAChD;;;;GAIG;AACH,eAAO,MAAM,YAAY,EAAE,OAAe,CAAC;AAC3C;;;;;GAKG;AACH,eAAO,MAAM,kBAAkB,EAAE,OAAe,CAAC;AACjD;;;;;;GAMG;AACH,eAAO,MAAM,eAAe,EAAE,OAAe,CAAC;AAC9C;;;;GAIG;AACH,eAAO,MAAM,SAAS,EAAE,OAAe,CAAC;AACxC;;;;;GAKG;AACH,eAAO,MAAM,kBAAkB,EAAE,OAAe,CAAC;AACjD;;;;;GAKG;AACH,eAAO,MAAM,iBAAiB,EAAE,OAAe,CAAC;AAChD;;;;;GAKG;AACH,eAAO,MAAM,gCAAgC,EAAE,OAAe,CAAC;AAE/D;;;;;;;;;GASG;AACH,eAAO,MAAM,oCAAoC,EAAE,OAAe,CAAC"}

package/unstable-preview-types/deprecation-versions.d.ts

@@ -1,485 +1,16 @@
 declare module '@warp-drive-mirror/build-config/deprecation-versions' {
-  /**
-   * @module @warp-drive-mirror/build-config
-   */
-  /**
-   * ## Deprecation Management
-   *
-   * EmberData allows users to opt-in and remove code that exists to support deprecated
-   * behaviors.
-   *
-   * If your app has resolved all deprecations present in a given version,
-   * you may specify that version as your "compatibility" version to remove
-   * the code that supported the deprecated behavior from your app.
-   *
-   * For instance, if a deprecation was introduced in 3.13, and the app specifies
-   * 3.13 as its minimum version compatibility, any deprecations introduced before
-   * or during 3.13 would be stripped away.
-   *
-   * An app can use a different version than what it specifies as it's compatibility
-   * version. For instance, an App could be using `3.16` while specifying compatibility
-   * with `3.12`. This would remove any deprecations that were present in or before `3.12`
-   * but keep support for anything deprecated in or above `3.13`.
-   *
-   * You may also specify that specific deprecations are resolved. These approaches
-   * may be used together.
-   *
-   * ```ts
-   * setConfig(app, __dirname, {
-   *   // that all deprecations through "5.0" have been fully resolved
-   *   compatWith: '5.0',
-   *
-   *   // mark individual deprecations as resolved by setting them to `false`
-   *   deprecations: {
-   *     // resolve individual deprecations here
-   *   },
-   * });
-   * ```
-   *
-   * > [!TIP]
-   * > EmberData does not test against permutations of deprecations
-   * > being stripped, our tests run against "all deprecated code included"
-   * > and "all deprecated code removed". Unspecified behavior may sometimes occur
-   * > when removing code for only some deprecations associated to a version number.
-   *
-   * @class CurrentDeprecations
-   * @public
-   */
   export const DEPRECATE_CATCH_ALL = "99.0";
-  /**
-   * **id: ember-data:deprecate-non-strict-types**
-   *
-   * Currently, EmberData expects that the `type` property associated with
-   * a resource follows several conventions.
-   *
-   * - The `type` property must be a non-empty string
-   * - The `type` property must be singular
-   * - The `type` property must be dasherized
-   *
-   * We are deprecating support for types that do not match this pattern
-   * in order to unlock future improvements in which we can support `type`
-   * being any string of your choosing.
-   *
-   * The goal is that in the future, you will be able to use any string
-   * so long as it matches what your configured cache, identifier generation,
-   * and schemas expect.
-   *
-   * E.G. It will matter not that your string is in a specific format like
-   * singular, dasherized, etc. so long as everywhere you refer to the type
-   * you use the same string.
-   *
-   * If using @ember-data-mirror/model, there will always be a restriction that the
-   * `type` must match the path on disk where the model is defined.
-   *
-   * e.g. `app/models/foo/bar-bem.js` must have a type of `foo/bar-bem`
-   *
-   * @property DEPRECATE_NON_STRICT_TYPES
-   * @type {Boolean}
-   * @since 5.3
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_NON_STRICT_TYPES = "5.3";
-  /**
-   * **id: ember-data:deprecate-non-strict-id**
-   *
-   * Currently, EmberData expects that the `id` property associated with
-   * a resource is a string.
-   *
-   * However, for legacy support in many locations we would accept a number
-   * which would then immediately be coerced into a string.
-   *
-   * We are deprecating this legacy support for numeric IDs.
-   *
-   * The goal is that in the future, you will be able to use any ID format
-   * so long as everywhere you refer to the ID you use the same format.
-   *
-   * However, for identifiers we will always use string IDs and so any
-   * custom identifier configuration should provide a string ID.
-   *
-   * @property DEPRECATE_NON_STRICT_ID
-   * @type {Boolean}
-   * @since 5.3
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_NON_STRICT_ID = "5.3";
-  /**
-   * **id: <none yet assigned>**
-   *
-   * This is a planned deprecation which will trigger when observer or computed
-   * chains are used to watch for changes on any EmberData LiveArray, CollectionRecordArray,
-   * ManyArray or PromiseManyArray.
-   *
-   * Support for these chains is currently guarded by the deprecation flag
-   * listed here, enabling removal of the behavior if desired.
-   *
-   * The instrumentation was added in 5.0 but the version number
-   * is set to 7.0 as we do not want to strip support without
-   * adding a deprecation message.
-   *
-   * Once we've added the deprecation message, we will
-   * update this version number to the proper version.
-   *
-   * @property DEPRECATE_COMPUTED_CHAINS
-   * @type {Boolean}
-   * @since 5.0
-   * @until 8.0
-   * @public
-   */
   export const DEPRECATE_COMPUTED_CHAINS = "7.0";
-  /**
-   * **id: ember-data:deprecate-legacy-imports**
-   *
-   * Deprecates when importing from `ember-data/*` instead of `@ember-data/*`
-   * in order to prepare for the eventual removal of the legacy `ember-data/*`
-   *
-   * All imports from `ember-data/*` should be updated to `@ember-data/*`
-   * except for `ember-data/store`. When you are using `ember-data` (as opposed to
-   * installing the indivudal packages) you should import from `ember-data/store`
-   * instead of `@ember-data-mirror/store` in order to receive the appropriate configuration
-   * of defaults.
-   *
-   * @property DEPRECATE_LEGACY_IMPORTS
-   * @type {Boolean}
-   * @since 5.3
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_LEGACY_IMPORTS = "5.3";
-  /**
-   * **id: ember-data:deprecate-non-unique-collection-payloads**
-   *
-   * Deprecates when the data for a hasMany relationship contains
-   * duplicate identifiers.
-   *
-   * Previously, relationships would silently de-dupe the data
-   * when received, but this behavior is being removed in favor
-   * of erroring if the same related record is included multiple
-   * times.
-   *
-   * For instance, in JSON:API the below relationship data would
-   * be considered invalid:
-   *
-   * ```json
-   * {
-   *  "data": {
-   *   "type": "article",
-   *    "id": "1",
-   *    "relationships": {
-   *      "comments": {
-   *        "data": [
-   *          { "type": "comment", "id": "1" },
-   *          { "type": "comment", "id": "2" },
-   *          { "type": "comment", "id": "1" } // duplicate
-   *        ]
-   *     }
-   *  }
-   * }
-   * ```
-   *
-   * To resolve this deprecation, either update your server to
-   * not include duplicate data, or implement normalization logic
-   * in either a request handler or serializer which removes
-   * duplicate data from relationship payloads.
-   *
-   * @property DEPRECATE_NON_UNIQUE_PAYLOADS
-   * @type {Boolean}
-   * @since 5.3
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_NON_UNIQUE_PAYLOADS = "5.3";
-  /**
-   * **id: ember-data:deprecate-relationship-remote-update-clearing-local-state**
-   *
-   * Deprecates when a relationship is updated remotely and the local state
-   * is cleared of all changes except for "new" records.
-   *
-   * Instead, any records not present in the new payload will be considered
-   * "removed" while any records present in the new payload will be considered "added".
-   *
-   * This allows us to "commit" local additions and removals, preserving any additions
-   * or removals that are not yet reflected in the remote state.
-   *
-   * For instance, given the following initial state:
-   *
-   * remote: A, B, C
-   * local: add D, E
-   *        remove B, C
-   * => A, D, E
-   *
-   *
-   * If after an update, the remote state is now A, B, D, F then the new state will be
-   *
-   * remote: A, B, D, F
-   * local: add E
-   *        remove B
-   * => A, D, E, F
-   *
-   * Under the old behavior the updated local state would instead have been
-   * => A, B, D, F
-   *
-   * Similarly, if a belongsTo remote State was A while its local state was B,
-   * then under the old behavior if the remote state changed to C, the local state
-   * would be updated to C. Under the new behavior, the local state would remain B.
-   *
-   * If the remote state was A while its local state was `null`, then under the old
-   * behavior if the remote state changed to C, the local state would be updated to C.
-   * Under the new behavior, the local state would remain `null`.
-   *
-   * Thus the new correct mental model is that the state of the relationship at any point
-   * in time is whatever the most recent remote state is, plus any local additions or removals
-   * you have made that have not yet been reflected by the remote state.
-   *
-   * > Note: The old behavior extended to modifying the inverse of a relationship. So if
-   * > you had local state not reflected in the new remote state, inverses would be notified
-   * > and their state reverted as well when "resetting" the relationship.
-   * > Under the new behavior, since the local state is preserved the inverses will also
-   * > not be reverted.
-   *
-   * ### Resolving this deprecation
-   *
-   * Resolving this deprecation can be done individually for each relationship
-   * or globally for all relationships.
-   *
-   * To resolve it globally, set the `DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE`
-   * to `false` in ember-cli-build.js
-   *
-   * ```js
-   * const { setConfig } = await import('@warp-drive-mirror/build-config');
-   *
-   * let app = new EmberApp(defaults, {});
-   *
-   * setConfig(app, __dirname, {
-   *   deprecations: {
-   *     // set to false to strip the deprecated code (thereby opting into the new behavior)
-   *     DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE: false
-   *   }
-   * });
-   * ```
-   *
-   * To resolve this deprecation on an individual relationship, adjust the `options` passed to
-   * the relationship. For relationships with inverses, both sides MUST be migrated to the new
-   * behavior at the same time.
-   *
-   * ```js
-   * class Person extends Model {
-   *  @hasMany('person', {
-   *    async: false,
-   *    inverse: null,
-   *    resetOnRemoteUpdate: false
-   *  }) children;
-   *
-   *  @belongsTo('person', {
-   *    async: false,
-   *    inverse: null,
-   *    resetOnRemoteUpdate: false
-   *  }) parent;
-   * }
-   * ```
-   *
-   * > Note: false is the only valid value here, all other values (including missing)
-   * > will be treated as true, where `true` is the legacy behavior that is now deprecated.
-   *
-   * Once you have migrated all relationships, you can remove the the resetOnRemoteUpdate
-   * option and set the deprecation flag to false in ember-cli-build.
-   *
-   * ### What if I don't want the new behavior?
-   *
-   * EmberData's philosophy is to not make assumptions about your application. Where possible
-   * we seek out "100%" solutions – solutions that work for all use cases - and where that is
-   * not possible we default to "90%" solutions – solutions that work for the vast majority of use
-   * cases. In the case of "90%" solutions we look for primitives that allow you to resolve the
-   * 10% case in your application. If no such primitives exist, we provide an escape hatch that
-   * ensures you can build the behavior you need without adopting the cost of the default solution.
-   *
-   * In this case, the old behavior was a "40%" solution. The inability for an application developer
-   * to determine what changes were made locally, and thus what changes should be preserved, made
-   * it impossible to build certain features easily, or in some cases at all. The proliferation of
-   * feature requests, bug reports (from folks surprised by the prior behavior) and addon attempts
-   * in this space are all evidence of this.
-   *
-   * We believe the new behavior is a "90%" solution. It works for the vast majority of use cases,
-   * often without noticeable changes to existing application behavior, and provides primitives that
-   * allow you to build the behavior you need for the remaining 10%.
-   *
-   * The great news is that this behavior defaults to trusting your API similar to the old behavior.
-   * If your API is correct, you will not need to make any changes to your application to adopt
-   * the new behavior.
-   *
-   * This means the 10% cases are those where you can't trust your API to provide the correct
-   * information. In these cases, because you now have cheap access to a diff of the relationship
-   * state, there are a few options that weren't available before:
-   *
-   * - you can adjust returned API payloads to contain the expected changes that it doesn't include
-   * - you can modify local state by adding or removing records on the HasMany record array to remove
-   *   any local changes that were not returned by the API.
-   * - you can use `<Cache>.mutate(mutation)` to directly modify the local cache state of the relationship
-   *   to match the expected state.
-   *
-   * What this version (5.3) does not yet provide is a way to directly modify the cache's remote state
-   * for the relationship via public APIs other than via the broader action of upserting a response via
-   * `<Cache>.put(document)`. However, such an API was sketched in the Cache 2.1 RFC
-   * `<Cache>.patch(operation)` and is likely to be added in a future 5.x release of EmberData.
-   *
-   * This version (5.3) also does not yet provide a way to directly modify the graph (a general purpose
-   * subset of cache behaviors specific to relationships) via public APIs. However, during the
-   * 5.x release series we will be working on finalizing the Graph API and making it public.
-   *
-   * If none of these options work for you, you can always opt-out more broadly by implementing
-   * a custom Cache with the relationship behaviors you need.
-   *
-   * @property DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE
-   * @type {Boolean}
-   * @since 5.3
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE = "5.3";
-  /**
-   * **id: ember-data:deprecate-many-array-duplicates**
-   *
-   * When the flag is `true` (default), adding duplicate records to a `ManyArray`
-   * is deprecated in non-production environments. In production environments,
-   * duplicate records added to a `ManyArray` will be deduped and no error will
-   * be thrown.
-   *
-   * When the flag is `false`, an error will be thrown when duplicates are added.
-   *
-   * @property DEPRECATE_MANY_ARRAY_DUPLICATES
-   * @type {Boolean}
-   * @since 5.3
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_MANY_ARRAY_DUPLICATES = "5.3";
-  /**
-   * **id: ember-data:deprecate-store-extends-ember-object**
-   *
-   * When the flag is `true` (default), the Store class will extend from `@ember/object`.
-   * When the flag is `false` or `ember-source` is not present, the Store will not extend
-   * from EmberObject.
-   *
-   * @property DEPRECATE_STORE_EXTENDS_EMBER_OBJECT
-   * @type {Boolean}
-   * @since 5.4
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_STORE_EXTENDS_EMBER_OBJECT = "5.4";
-  /**
-   * **id: ember-data:schema-service-updates**
-   *
-   * When the flag is `true` (default), the legacy schema
-   * service features will be enabled on the store and
-   * the service, and deprecations will be thrown when
-   * they are used.
-   *
-   * Deprecated features include:
-   *
-   * - `Store.registerSchema` method is deprecated in favor of the `Store.createSchemaService` hook
-   * - `Store.registerSchemaDefinitionService` method is deprecated in favor of the `Store.createSchemaService` hook
-   * - `Store.getSchemaDefinitionService` method is deprecated in favor of `Store.schema` property
-   * - `SchemaService.doesTypeExist` method is deprecated in favor of the `SchemaService.hasResource` method
-   * - `SchemaService.attributesDefinitionFor` method is deprecated in favor of the `SchemaService.fields` method
-   * - `SchemaService.relationshipsDefinitionFor` method is deprecated in favor of the `SchemaService.fields` method
-   *
-   * @property ENABLE_LEGACY_SCHEMA_SERVICE
-   * @type {Boolean}
-   * @since 5.4
-   * @until 6.0
-   * @public
-   */
   export const ENABLE_LEGACY_SCHEMA_SERVICE = "5.4";
-  /**
-   * **id: warp-drive.ember-inflector**
-   *
-   * Deprecates the use of ember-inflector for pluralization and singularization in favor
-   * of the `@ember-data-mirror/request-utils` package.
-   *
-   * Rule configuration methods (singular, plural, uncountable, irregular) and
-   * usage methods (singularize, pluralize) are are available as imports from
-   * `@ember-data-mirror/request-utils/string`
-   *
-   * Notable differences with ember-inflector:
-   * - there cannot be multiple inflector instances with separate rules
-   * - pluralization does not support a count argument
-   * - string caches now default to 10k entries instead of 1k, and this
-   *   size is now configurable. Additionally, the cache is now a LRU cache
-   *   instead of a first-N cache.
-   *
-   * This deprecation can be resolved by removing usage of ember-inflector or by using
-   * both ember-inflector and @ember-data-mirror/request-utils in parallel and updating your
-   * EmberData/WarpDrive build config to mark the deprecation as resolved
-   * in ember-cli-build
-   *
-   * ```js
-   * setConfig(app, __dirname, { deprecations: { DEPRECATE_EMBER_INFLECTOR: false }});
-   * ```
-   *
-   * @property DEPRECATE_EMBER_INFLECTOR
-   * @type {Boolean}
-   * @since 5.3
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_EMBER_INFLECTOR = "5.3";
-  /**
-   * This is a special flag that can be used to opt-in early to receiving deprecations introduced in 6.x
-   * which have had their infra backported to 5.x versions of EmberData.
-   *
-   * When this flag is not present or set to `true`, the deprecations from the 6.x branch
-   * will not print their messages and the deprecation cannot be resolved.
-   *
-   * When this flag is present and set to `false`, the deprecations from the 6.x branch will
-   * print and can be resolved.
-   *
-   * @property DISABLE_7X_DEPRECATIONS
-   * @type {Boolean}
-   * @since 5.3
-   * @until 7.0
-   * @public
-   */
   export const DISABLE_7X_DEPRECATIONS = "7.0";
-  /**
-   * **id: warp-drive:deprecate-tracking-package**
-   *
-   * Deprecates the use of the @ember-data-mirror/tracking package which
-   * historically provided bindings into Ember's reactivity system.
-   *
-   * This package is no longer needed as the configuration is now
-   * provided by the @warp-drive-mirror/ember package.
-   *
-   * This deprecation can be resolved by removing the
-   * @ember-data-mirror/tracking package from your project and ensuring
-   * that your app.js file has the following import:
-   *
-   * ```js
-   * import '@warp-drive-mirror/ember/install';
-   * ```
-   *
-   * Once this import is present, you can remove the deprecation
-   * by setting the deprecation to `false` in your build config:
-   *
-   * ```js
-   * // inside of ember-cli-build.js
-   *
-   * const { setConfig } = await import('@warp-drive-mirror/build-config');
-   *
-   * setConfig(app, __dirname, {
-   *   deprecations: {
-   *     DEPRECATE_TRACKING_PACKAGE: false
-   *   }
-   * });
-   * ```
-   *
-   * @property DEPRECATE_TRACKING_PACKAGE
-   * @type {Boolean}
-   * @since 5.5
-   * @until 6.0
-   * @public
-   */
   export const DEPRECATE_TRACKING_PACKAGE = "5.5";
 }
 //# sourceMappingURL=deprecation-versions.d.ts.map