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

package/dist/deprecations-BVxAmwe9.js

@@ -0,0 +1,549 @@
+/**
+ * # Deprecations
+ *
+ * This guide is intended to help you understand both how to address an active
+ * deprecation and how to eliminate the code that supports the deprecation once
+ * it has been resolved.
+ *
+ * Eliminating the associated code reduces the size of your application, often opts
+ * applications into more performant fast-paths, and ensures your application does
+ * not revert to using the deprecated behavior in the future.
+ *
+ * ## Active Deprecation IDs
+ *
+ * - {@link DEPRECATE_NON_STRICT_TYPES | ember-data:deprecate-non-strict-types}
+ * - {@link DEPRECATE_NON_STRICT_ID | ember-data:deprecate-non-strict-id}
+ * - {@link DEPRECATE_LEGACY_IMPORTS | ember-data:deprecate-legacy-imports}
+ * - {@link DEPRECATE_NON_UNIQUE_PAYLOADS | ember-data:deprecate-non-unique-collection-payloads}
+ * - {@link DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE | ember-data:deprecate-relationship-remote-update-clearing-local-state}
+ * - {@link DEPRECATE_MANY_ARRAY_DUPLICATES | ember-data:deprecate-many-array-duplicates}
+ * - {@link DEPRECATE_STORE_EXTENDS_EMBER_OBJECT | ember-data:deprecate-store-extends-ember-object}
+ * - {@link ENABLE_LEGACY_SCHEMA_SERVICE | ember-data:schema-service-updates}
+ * - {@link DEPRECATE_EMBER_INFLECTOR | warp-drive.ember-inflector}
+ * - {@link DEPRECATE_TRACKING_PACKAGE | warp-drive:deprecate-tracking-package}
+ *
+ * ## Removing Code for Deprecated Features
+ *
+ * ***Warp*Drive** enables applications to opt-in to fully eliminating the code
+ * for a deprecated feature once the application has taken the necessary steps to
+ * ensure that it no longer requires the use of the code which triggers the deprecation.
+ *
+ * Each deprecation ID is associated to a deprecation flag which is used to instrument
+ * the library for build-time removal of the deprecated code. Some flags have multiple
+ * deprecation IDs associated to them, in which case to remove the deprecated code all
+ * of the deprecation IDs must be resolved.
+ *
+ *
+ * There are two modes for opting into deprecated code removal:
+ *
+ * - by version
+ * - by deprecation flag
+ *
+ * If your app has resolved all deprecations present in a given version,
+ * you may specify that version as your "compatWith" version. This will
+ * remove the code for all deprecations that were introduced in or before
+ * that version.
+ *
+ * ::: code-group
+ *
+ * ```ts [ember-cli-build.js]
+ * setConfig(app, __dirname, {
+ *   compatWith: '5.0', // [!code highlight]
+ * });
+ * ```
+ *
+ * ```ts [babel.config.mjs]
+ * setConfig(context, {
+ *   compatWith: '5.0', // [!code highlight]
+ * });
+ * ```
+ *
+ * :::
+ *
+ * For instance, if a deprecation was introduced in 5.3, and the app specifies
+ * 5.2 as its minimum version compatibility, any deprecations introduced in or
+ * before 5.2 will be removed, but any deprecations introduced in 5.3 will remain.
+ *
+ * You may also specify that specific deprecations are resolved. These approaches
+ * may be used together.
+ *
+ * ::: code-group
+ *
+ * ```ts [ember-cli-build.js]
+ * setConfig(app, __dirname, {
+ *  deprecations: {
+ *    DEPRECATE_NON_STRICT_TYPES: false, // [!code highlight]
+ *    DEPRECATE_NON_STRICT_ID: false, // [!code highlight]
+ *  }
+ * });
+ * ```
+ *
+ * ```ts [babel.config.mjs]
+ * setConfig(context, {
+ *   deprecations: {
+ *     DEPRECATE_NON_STRICT_TYPES: false, // [!code highlight]
+ *     DEPRECATE_NON_STRICT_ID: false, // [!code highlight]
+ *   }
+ * });
+ * ```
+ *
+ * :::
+ *
+ *
+ * ::: info 💡 Report Bugs if You Find Them
+ * ***Warp*Drive** 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 specific deprecations.
+ *
+ * If this happens, we'd like to know 💜
+ * :::
+ *
+ * @module
+ */
+
+/** @internal */
+const DEPRECATE_CATCH_ALL = true;
+
+/**
+ * <Badge type="danger" text="no-id-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.
+ *
+ * @since 5.0
+ * @until 8.0
+ * @public
+ */
+const DEPRECATE_COMPUTED_CHAINS = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror:deprecate-non-strict-types" />
+ *
+ * Currently, ***Warp*Drive** 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`
+ *
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_NON_STRICT_TYPES = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror: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.
+ *
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_NON_STRICT_ID = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror: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.
+ *
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_LEGACY_IMPORTS = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror: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.
+ *
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_NON_UNIQUE_PAYLOADS = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror: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.
+ *
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror: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.
+ *
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_MANY_ARRAY_DUPLICATES = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror: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.
+
+ * @since 5.4
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_STORE_EXTENDS_EMBER_OBJECT = true;
+
+/**
+ * <Badge type="warning" text="ember-data-mirror: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
+ *
+ * @since 5.4
+ * @until 6.0
+ * @public
+ */
+const ENABLE_LEGACY_SCHEMA_SERVICE = true;
+
+/**
+ * <Badge type="warning" text=" 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 }});
+ * ```
+ *
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_EMBER_INFLECTOR = true;
+
+/**
+ * <Badge type="warning" text="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
+ *   }
+ * });
+ * ```
+ *
+ * @since 5.5
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_TRACKING_PACKAGE = true;
+
+/**
+ * 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 ***Warp*Drive**.
+ *
+ * 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.
+ *
+ * @since 5.3
+ * @until 7.0
+ * @public
+ */
+const DISABLE_7X_DEPRECATIONS = true;
+
+const CURRENT_DEPRECATIONS = /*#__PURE__*/Object.freeze(/*#__PURE__*/Object.defineProperty({
+	__proto__: null,
+	DEPRECATE_CATCH_ALL,
+	DEPRECATE_COMPUTED_CHAINS,
+	DEPRECATE_EMBER_INFLECTOR,
+	DEPRECATE_LEGACY_IMPORTS,
+	DEPRECATE_MANY_ARRAY_DUPLICATES,
+	DEPRECATE_NON_STRICT_ID,
+	DEPRECATE_NON_STRICT_TYPES,
+	DEPRECATE_NON_UNIQUE_PAYLOADS,
+	DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE,
+	DEPRECATE_STORE_EXTENDS_EMBER_OBJECT,
+	DEPRECATE_TRACKING_PACKAGE,
+	DISABLE_7X_DEPRECATIONS,
+	ENABLE_LEGACY_SCHEMA_SERVICE
+}, Symbol.toStringTag, { value: 'Module' }));
+
+export { CURRENT_DEPRECATIONS as C, DEPRECATE_CATCH_ALL as D, ENABLE_LEGACY_SCHEMA_SERVICE as E, DEPRECATE_COMPUTED_CHAINS as a, DEPRECATE_NON_STRICT_TYPES as b, DEPRECATE_NON_STRICT_ID as c, DEPRECATE_LEGACY_IMPORTS as d, DEPRECATE_NON_UNIQUE_PAYLOADS as e, DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE as f, DEPRECATE_MANY_ARRAY_DUPLICATES as g, DEPRECATE_STORE_EXTENDS_EMBER_OBJECT as h, DEPRECATE_EMBER_INFLECTOR as i, DEPRECATE_TRACKING_PACKAGE as j, DISABLE_7X_DEPRECATIONS as k };
+//# sourceMappingURL=deprecations-BVxAmwe9.js.map

package/dist/deprecations-BVxAmwe9.js.map

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

package/dist/deprecations.js

@@ -1,2 +1,2 @@
-export { D as DEPRECATE_CATCH_ALL, a as DEPRECATE_COMPUTED_CHAINS, i as DEPRECATE_EMBER_INFLECTOR, d as DEPRECATE_LEGACY_IMPORTS, g as DEPRECATE_MANY_ARRAY_DUPLICATES, c as DEPRECATE_NON_STRICT_ID, b as DEPRECATE_NON_STRICT_TYPES, e as DEPRECATE_NON_UNIQUE_PAYLOADS, f as DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE, h as DEPRECATE_STORE_EXTENDS_EMBER_OBJECT, k as DEPRECATE_TRACKING_PACKAGE, j as DISABLE_7X_DEPRECATIONS, E as ENABLE_LEGACY_SCHEMA_SERVICE } from './deprecations-D_dBAPC9.js';
+export { D as DEPRECATE_CATCH_ALL, a as DEPRECATE_COMPUTED_CHAINS, i as DEPRECATE_EMBER_INFLECTOR, d as DEPRECATE_LEGACY_IMPORTS, g as DEPRECATE_MANY_ARRAY_DUPLICATES, c as DEPRECATE_NON_STRICT_ID, b as DEPRECATE_NON_STRICT_TYPES, e as DEPRECATE_NON_UNIQUE_PAYLOADS, f as DEPRECATE_RELATIONSHIP_REMOTE_UPDATE_CLEARING_LOCAL_STATE, h as DEPRECATE_STORE_EXTENDS_EMBER_OBJECT, j as DEPRECATE_TRACKING_PACKAGE, k as DISABLE_7X_DEPRECATIONS, E as ENABLE_LEGACY_SCHEMA_SERVICE } from './deprecations-BVxAmwe9.js';
 //# sourceMappingURL=deprecations.js.map