@warp-drive-mirror/build-config 0.0.0-beta.1 → 0.0.0-beta.3

package/dist/cjs-set-config.cjs

@@ -0,0 +1,860 @@
+'use strict';
+
+Object.defineProperty(exports, Symbol.toStringTag, { value: 'Module' });
+
+const EmbroiderMacros = require('@embroider/macros/src/node.js');
+const semver = require('semver');
+const fs = require('fs');
+const path = require('path');
+const url = require('url');
+
+var _documentCurrentScript = typeof document !== 'undefined' ? document.currentScript : null;
+function getEnv() {
+  const {
+    EMBER_ENV,
+    IS_TESTING,
+    EMBER_CLI_TEST_COMMAND,
+    NODE_ENV
+  } = process.env;
+  const PRODUCTION = EMBER_ENV === 'production' || !EMBER_ENV && NODE_ENV === 'production';
+  const DEBUG = !PRODUCTION;
+  const TESTING = DEBUG || Boolean(EMBER_ENV === 'test' || IS_TESTING || EMBER_CLI_TEST_COMMAND);
+  return {
+    TESTING,
+    PRODUCTION,
+    DEBUG
+  };
+}
+
+// ========================
+// FOR CONTRIBUTING AUTHORS
+//
+// Deprecations here should also have guides PR'd to the emberjs deprecation app
+//
+// github: https://github.com/ember-learn/deprecation-app
+// website: https://deprecations.emberjs.com
+//
+// Each deprecation should also be given an associated URL pointing to the
+// relevant guide.
+//
+// URLs should be of the form: https://deprecations.emberjs.com/v<major>.x#toc_<fileName>
+// where <major> is the major version of the deprecation and <fileName> is the
+// name of the markdown file in the guides repo.
+//
+// ========================
+//
+
+/**
+ * ## Deprecations
+ *
+ * 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`.
+ *
+ * ### Configuring Compatibility
+ *
+ * To configure your compatibility version, set the `compatWith` to the version you
+ * are compatible with on the `emberData` config in your `ember-cli-build.js` file.
+ *
+ * ```js
+ * const { setConfig } = await import('@warp-drive-mirror/build-config');
+ *
+ * let app = new EmberApp(defaults, {});
+ *
+ * setConfig(app, __dirname, { compatWith: '3.12' });
+ * ```
+ *
+ * Alternatively, individual deprecations can be resolved (and thus have its support stripped)
+ * via one of the flag names listed below. For instance, given a flag named `DEPRECATE_FOO_BEHAVIOR`.
+ *
+ * This capability is interopable with `compatWith`. You may set `compatWith` and then selectively resolve
+ * additional deprecations, or set compatWith and selectively un-resolve specific deprecations.
+ *
+ * Note: 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.
+ *
+ * ```js
+ * const { setConfig } = await import('@warp-drive-mirror/build-config');
+ *
+ * let app = new EmberApp(defaults, {});
+ *
+ * setConfig(app, __dirname, {
+ *   deprecations: {
+ *     DEPRECATE_FOO_BEHAVIOR: false // set to false to strip this code
+ *     DEPRECATE_BAR_BEHAVIOR: true // force to true to not strip this code
+ *   }
+ * });
+ * ```
+ *
+ * The complete list of which versions specific deprecations will be removed in
+ * can be found [here](https://github.com/emberjs/data/blob/main/packages/build-config/src/virtual/deprecation-versions.ts "List of EmberData Deprecations")
+ *
+ * @module @warp-drive-mirror/build-config/deprecations
+ * @main @warp-drive-mirror/build-config/deprecations
+ */
+
+/**
+ * The following list represents deprecations currently active.
+ *
+ * Some deprecation flags guard multiple deprecation IDs. All
+ * associated IDs are listed.
+ *
+ * @class CurrentDeprecations
+ * @public
+ */
+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
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+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
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+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.
+ *
+ * @property DEPRECATE_COMPUTED_CHAINS
+ * @since 5.0
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_COMPUTED_CHAINS = '5.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
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+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
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+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
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+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
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+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
+ * @since 5.4
+ * @until 6.0
+ * @public
+ */
+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
+ * @since 5.4
+ * @until 6.0
+ * @public
+ */
+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
+ * @since 5.3
+ * @until 6.0
+ * @public
+ */
+const DEPRECATE_EMBER_INFLECTOR = '5.3';
+
+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,
+  ENABLE_LEGACY_SCHEMA_SERVICE
+}, Symbol.toStringTag, { value: 'Module' }));
+
+function deprecationIsResolved(deprecatedSince, compatVersion) {
+  return semver.lte(semver.minVersion(deprecatedSince), semver.minVersion(compatVersion));
+}
+function getDeprecations(compatVersion) {
+  const flags = {};
+  const keys = Object.keys(CURRENT_DEPRECATIONS);
+  keys.forEach(flag => {
+    const deprecatedSince = CURRENT_DEPRECATIONS[flag];
+    let flagState = true; // default to no code-stripping
+
+    // if we are told we are compatible with a version
+    // we check if we can strip this flag
+    if (compatVersion) {
+      const isResolved = deprecationIsResolved(deprecatedSince, compatVersion);
+      // if we've resolved, we strip (by setting the flag to false)
+      /*
+        if (DEPRECATED_FEATURE) {
+          // deprecated code path
+        } else {
+          // if needed a non-deprecated code path
+        }
+      */
+      flagState = !isResolved;
+    }
+
+    // console.log(`${flag}=${flagState} (${deprecatedSince} <= ${compatVersion})`);
+    flags[flag] = flagState;
+  });
+  return flags;
+}
+
+/**
+ * ## Canary Features
+ *
+ * EmberData allows users to test features that are implemented but not yet
+ * available even in canary.
+ *
+ * Typically these features represent work that might introduce a new concept,
+ * new API, change an API, or risk an unintended change in behavior to consuming
+ * applications.
+ *
+ * Such features have their implementations guarded by a "feature flag", and the
+ * flag is only activated once the core-data team is prepared to ship the work
+ * in a canary release.
+ *
+ * ### Installing Canary
+ *
+ * To test a feature you MUST be using a canary build. Canary builds are published
+ * to `npm` and can be installed using a precise tag (such as `ember-data@3.16.0-alpha.1`)
+ * or by installing the latest dist-tag published to the `canary` channel using your javascript
+ * package manager of choice. For instance with [pnpm](https://pnpm.io/)
+
+  ```cli
+  pnpm add ember-data@canary
+  ```
+ *
+ * ### Activating a Canary Feature
+ *
+ * Once you have installed canary, feature-flags can be activated at build-time
+ *
+ * by setting an environment variable:
+ *
+ * ```cli
+ * # Activate a single flag
+ * EMBER_DATA_FEATURE_OVERRIDE=SOME_FLAG ember build
+ *
+ * # Activate multiple flags by separating with commas
+ * EMBER_DATA_FEATURE_OVERRIDE=SOME_FLAG,OTHER_FLAG ember build
+ *
+ * # Activate all flags
+ * EMBER_DATA_FEATURE_OVERRIDE=ENABLE_ALL_OPTIONAL ember build
+ * ```
+ *
+ * or by setting the appropriate flag in your `ember-cli-build` file:
+ *
+ * ```ts
+ * let app = new EmberApp(defaults, {
+ *   emberData: {
+ *     features: {
+ *       SAMPLE_FEATURE_FLAG: false // utliize existing behavior, strip code for the new feature
+ *       OTHER_FEATURE_FLAG: true // utilize this new feature, strip code for the older behavior
+ *     }
+ *   }
+ * })
+ * ```
+ *
+ * **The "off" branch of feature-flagged code is always stripped from production builds.**
+ *
+ * The list of available feature-flags is located [here](https://github.com/emberjs/data/tree/main/packages/build-config/src/virtual/canary-features.ts "List of EmberData FeatureFlags")
+ *
+ *
+ * ### Preparing a Project to use a Canary Feature
+ *
+ * For most projects, simple version detection should be enough.
+ * Using the provided version compatibility helpers from [embroider-macros](https://github.com/embroider-build/embroider/tree/main/packages/macros#readme)
+ * the following can be done:
+ *
+ * ```js
+ * if (macroCondition(dependencySatisfies('@ember-data-mirror/store', '5.0'))) {
+ *   // do thing
+ * }
+ * ```
+ *
+   @module @warp-drive-mirror/build-config/canary-features
+   @main @warp-drive-mirror/build-config/canary-features
+ */
+/**
+  This is the current list of features used at build time for canary releases.
+  If empty there are no features currently gated by feature flags.
+
+  The valid values are:
+
+  - `true` | The feature is **enabled** at all times, and cannot be disabled.
+  - `false` | The feature is **disabled** at all times, and cannot be enabled.
+  - `null` | The feature is **disabled by default**, but can be enabled via configuration.
+
+  @class CanaryFeatureFlags
+  @public
+*/
+const SAMPLE_FEATURE_FLAG = null;
+
+const CURRENT_FEATURES = /*#__PURE__*/Object.freeze(/*#__PURE__*/Object.defineProperty({
+  __proto__: null,
+  SAMPLE_FEATURE_FLAG
+}, Symbol.toStringTag, { value: 'Module' }));
+
+const dirname = typeof __dirname !== 'undefined' ? __dirname : url.fileURLToPath(new URL(".", (typeof document === 'undefined' ? require('u' + 'rl').pathToFileURL(__filename).href : (_documentCurrentScript && _documentCurrentScript.src || new URL('cjs-set-config.cjs', document.baseURI).href))));
+const relativePkgPath = path.join(dirname, '../package.json');
+const version = JSON.parse(fs.readFileSync(relativePkgPath, 'utf-8')).version;
+const isCanary = version.includes('alpha');
+function getFeatures(isProd) {
+  const features = Object.assign({}, CURRENT_FEATURES);
+  const keys = Object.keys(features);
+  if (!isCanary) {
+    // disable all features with a current value of `null`
+    for (const feature of keys) {
+      let featureValue = features[feature];
+      if (featureValue === null) {
+        features[feature] = false;
+      }
+    }
+    return features;
+  }
+  const FEATURE_OVERRIDES = process.env.EMBER_DATA_FEATURE_OVERRIDE;
+  if (FEATURE_OVERRIDES === 'ENABLE_ALL_OPTIONAL') {
+    // enable all features with a current value of `null`
+    for (const feature of keys) {
+      let featureValue = features[feature];
+      if (featureValue === null) {
+        features[feature] = true;
+      }
+    }
+  } else if (FEATURE_OVERRIDES === 'DISABLE_ALL') {
+    // disable all features, including those with a value of `true`
+    for (const feature of keys) {
+      features[feature] = false;
+    }
+  } else if (FEATURE_OVERRIDES) {
+    // enable only the specific features listed in the environment
+    // variable (comma separated)
+    const forcedFeatures = FEATURE_OVERRIDES.split(',');
+    for (let i = 0; i < forcedFeatures.length; i++) {
+      let featureName = forcedFeatures[i];
+      if (!keys.includes(featureName)) {
+        throw new Error(`Unknown feature flag: ${featureName}`);
+      }
+      features[featureName] = true;
+    }
+  }
+  if (isProd) {
+    // disable all features with a current value of `null`
+    for (const feature of keys) {
+      let featureValue = features[feature];
+      if (featureValue === null) {
+        features[feature] = false;
+      }
+    }
+  }
+  return features;
+}
+
+/**
+ * ## Debugging
+ *
+ * Many portions of the internals are helpfully instrumented with logging that can be activated
+ * at build time. This instrumentation is always removed from production builds or any builds
+ * that has not explicitly activated it. To activate it set the appropriate flag to `true`.
+ *
+  @module @warp-drive-mirror/build-config/debugging
+  @main @warp-drive-mirror/build-config/debugging
+ */
+/**
+ *
+ * Many portions of the internals are helpfully instrumented with logging that can be activated
+at build time. This instrumentation is always removed from production builds or any builds
+that has not explicitly activated it. To activate it set the appropriate flag to `true`.
+
+```ts
+  let app = new EmberApp(defaults, {
+    emberData: {
+      debug: {
+          LOG_PAYLOADS: false, // data store received to update cache with
+          LOG_OPERATIONS: false, // updates to cache remote state
+          LOG_MUTATIONS: false, // updates to cache local state
+          LOG_NOTIFICATIONS: false,
+          LOG_REQUESTS: false,
+          LOG_REQUEST_STATUS: false,
+          LOG_IDENTIFIERS: false,
+          LOG_GRAPH: false,
+          LOG_INSTANCE_CACHE: false,
+      }
+    }
+  });
+  ```
+
+  @class DebugLogging
+  @public
+ */
+/**
+ * log payloads received by the store
+ * via `push` or returned from a delete/update/create
+ * operation.
+ *
+ * @property {boolean} LOG_PAYLOADS
+ * @public
+ */
+const LOG_PAYLOADS = false;
+/**
+ * log remote-state updates to the cache
+ *
+ * @property {boolean} LOG_OPERATIONS
+ * @public
+ */
+const LOG_OPERATIONS = false;
+/**
+ * log local-state updates to the cache
+ *
+ * @property {boolean} LOG_MUTATIONS
+ * @public
+ */
+const LOG_MUTATIONS = false;
+/**
+ * log notifications received by the NotificationManager
+ *
+ * @property {boolean} LOG_NOTIFICATIONS
+ * @public
+ */
+const LOG_NOTIFICATIONS = false;
+/**
+ * log requests issued by the RequestManager
+ *
+ * @property {boolean} LOG_REQUESTS
+ * @public
+ */
+const LOG_REQUESTS = false;
+/**
+ * log updates to requests the store has issued to
+ * the network (adapter) to fulfill.
+ *
+ * @property {boolean} LOG_REQUEST_STATUS
+ * @public
+ */
+const LOG_REQUEST_STATUS = false;
+/**
+ * log peek, generation and updates to
+ * Record Identifiers.
+ *
+ * @property {boolean} LOG_IDENTIFIERS
+ * @public
+ */
+const LOG_IDENTIFIERS = false;
+/**
+ * log updates received by the graph (relationship pointer storage)
+ *
+ * @property {boolean} LOG_GRAPH
+ * @public
+ */
+const LOG_GRAPH = false;
+/**
+ * log creation/removal of RecordData and Record
+ * instances.
+ *
+ * @property {boolean} LOG_INSTANCE_CACHE
+ * @public
+ */
+const LOG_INSTANCE_CACHE = false;
+
+const LOGGING = /*#__PURE__*/Object.freeze(/*#__PURE__*/Object.defineProperty({
+  __proto__: null,
+  LOG_GRAPH,
+  LOG_IDENTIFIERS,
+  LOG_INSTANCE_CACHE,
+  LOG_MUTATIONS,
+  LOG_NOTIFICATIONS,
+  LOG_OPERATIONS,
+  LOG_PAYLOADS,
+  LOG_REQUESTS,
+  LOG_REQUEST_STATUS
+}, Symbol.toStringTag, { value: 'Module' }));
+
+const _MacrosConfig = EmbroiderMacros.MacrosConfig;
+function recastMacrosConfig(macros) {
+  if (!('globalConfig' in macros)) {
+    throw new Error('Expected MacrosConfig to have a globalConfig property');
+  }
+  return macros;
+}
+function setConfig(context, appRoot, config) {
+  const macros = recastMacrosConfig(_MacrosConfig.for(context, appRoot));
+  const isLegacySupport = config.___legacy_support;
+  const hasDeprecatedConfig = isLegacySupport && Object.keys(config).length > 1;
+  const hasInitiatedConfig = macros.globalConfig['WarpDrive'];
+
+  // setConfig called by user prior to legacy support called
+  if (isLegacySupport && hasInitiatedConfig) {
+    if (hasDeprecatedConfig) {
+      throw new Error('You have provided a config object to setConfig, but are also using the legacy emberData options key in ember-cli-build. Please remove the emberData key from options.');
+    }
+    return;
+  }
+
+  // legacy support called prior to user setConfig
+  if (isLegacySupport && hasDeprecatedConfig) {
+    console.warn(`You are using the legacy emberData key in your ember-cli-build.js file. This key is deprecated and will be removed in the next major version of EmberData/WarpDrive. Please use \`import { setConfig } from '@warp-drive-mirror/build-config';\` instead.`);
+  }
+
+  // included hooks run during class initialization of the EmberApp instance
+  // so our hook will run before the user has a chance to call setConfig
+  // else we could print a useful message here
+  // else if (isLegacySupport) {
+  //   console.warn(
+  //     `WarpDrive requires your ember-cli-build file to set a base configuration for the project.\n\nUsage:\n\t\`import { setConfig } from '@warp-drive-mirror/build-config';\n\tsetConfig(app, __dirname, {});\``
+  //   );
+  // }
+
+  const debugOptions = Object.assign({}, LOGGING, config.debug);
+  const env = getEnv();
+  const DEPRECATIONS = getDeprecations(config.compatWith || null);
+  const FEATURES = getFeatures(env.PRODUCTION);
+  const includeDataAdapterInProduction = typeof config.includeDataAdapterInProduction === 'boolean' ? config.includeDataAdapterInProduction : false;
+  const includeDataAdapter = env.PRODUCTION ? includeDataAdapterInProduction : false;
+  const finalizedConfig = {
+    debug: debugOptions,
+    polyfillUUID: config.polyfillUUID ?? false,
+    includeDataAdapter,
+    compatWith: config.compatWith ?? null,
+    deprecations: DEPRECATIONS,
+    features: FEATURES,
+    env
+  };
+  macros.setGlobalConfig(undefined, 'WarpDrive', finalizedConfig);
+}
+
+exports.setConfig = setConfig;
+//# sourceMappingURL=cjs-set-config.cjs.map