From 270c4df3b21c7d9322b39fedd6e7b81ec180035e Mon Sep 17 00:00:00 2001 From: Chris Thoburn Date: Fri, 25 Sep 2026 18:55:10 +0000 Subject: [PATCH 1/2] Add RFC: WarpDrive: Deprecating the Legacy ember-data Packages and @warp-drive/core-types --- ...data-packages-and-warp-drive-core-types.md | 404 ++++++++++++++++++ 1 file changed, 404 insertions(+) create mode 100644 text/0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md diff --git a/text/0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md b/text/0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md new file mode 100644 index 0000000000..524731724c --- /dev/null +++ b/text/0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md @@ -0,0 +1,404 @@ +--- +stage: proposed +start-date: 2026-09-25T00:00:00.000Z +release-date: +release-versions: +teams: + - data + - learning +prs: + accepted: +project-link: +suite: +--- + +# WarpDrive: Deprecating the Legacy ember-data Packages and @warp-drive/core-types + +## Summary + +The `ember-data` package, every `@ember-data/*` package (`active-record`, `adapter`, `codemods`, +`debug`, `graph`, `json-api`, `legacy-compat`, `model`, `request`, `request-utils`, `rest`, +`serializer`, `store`, `tracking`), and `@warp-drive/core-types` are deprecated starting in the +next 5.x minor, with removal from npm publishing at 6.0. Most of these are already, today, a +thin re-export shim over a `@warp-drive/*` package introduced by the package-unification effort +([emberjs/rfcs#1075](https://rfcs.emberjs.com/id/1075-warp-drive-package-unification/)) — +`@warp-drive/core`, `@warp-drive/legacy`, `@warp-drive/utilities`, `@warp-drive/json-api`, and +`@warp-drive/ember`. The two exceptions get a successor as part of this RFC rather than reusing +an existing shim: `@ember-data/debug`'s ember-inspector integration is superseded by the +WarpDrive DevTools browser extension proposed in +[RFC 0003](./0003-warp-drive-devtools-extension.md), and `@ember-data/codemods` is renamed to +`@warp-drive/codemods`. For the rest, this RFC does not move any logic; it formalizes the +deprecation of the old import paths that RFC 1075 already implied, with concrete deprecation +flags/ids and documentation updates, landing now, on the same `since <5.x>` / `until 6.0` +timeline every other active deprecation in `deprecations.ts` already uses. The mechanical import +rewrite itself needs no new tooling: `eslint-plugin-warp-drive`'s `no-legacy-imports` rule +already autofixes exactly this rename, and already ships enabled in its `recommended` config. + +## Motivation + +RFC 1075 unified WarpDrive's packages so that an app installs `@warp-drive/core` and a small +number of framework/feature packages instead of assembling a dozen `@ember-data/*` packages by +hand. That work is done: every legacy package's `src/index.ts` is now nothing but a re-export. +For example: + +```ts +// packages/store/src/index.ts +export { Store as default } from '@warp-drive/core'; +``` + +```ts +// packages/core-types/src/index.ts +export type * from '@warp-drive/core/types'; +``` + +Despite this, the legacy packages are still published, versioned in lockstep with everything +else, documented as a first-class install path (`guides/configuration/legacy-package-setup` +still lists `@ember-data/store`, `@ember-data/request`, `@warp-drive/core-types`, etc. as "the +current setup"), and tested as if they were independent implementations. Carrying two import +paths to the same code indefinitely means: + +- **Doubled documentation and onboarding surface.** New users following the legacy setup guide + learn a five-to-fourteen-package install command for functionality that `@warp-drive/core` + (plus at most `@warp-drive/ember`) already provides in one or two packages. +- **A confusing dependency graph for tooling.** Bundlers, TypeScript, and vite in particular + handle the `ember-data` meta-package's automatic dependency bundling poorly (already called + out in the legacy setup guide's own "What about the `ember-data` package?" section) — the + fix has existed since RFC 1075 shipped, but nothing tells an app it should stop relying on the + meta-package. +- **No signal that the shims are temporary.** `@warp-drive/core-types`'s package description + already says `(Legacy)`, but nothing else — no build-time warning, no npm deprecation notice, + no migration guide — tells a consumer that importing from `@ember-data/model` instead of + `@warp-drive/legacy/model` is a choice with an expiration date. + +The expected outcome: starting in the next 5.x minor, every consumer importing from a legacy +package sees a clear, actionable deprecation pointing at the exact `@warp-drive/*` replacement +import, with `eslint --fix` performing the rewrite mechanically via the already-shipping +`no-legacy-imports` rule; at 6.0, WarpDrive stops publishing new versions of the legacy packages, +and the legacy setup guide is replaced entirely by the unified one. + +## Detailed design + +### What's covered and what it maps to + +Every legacy package's replacement — a re-export target confirmed by reading its `src/index.ts` +for most of them, or a successor this RFC introduces for the two that don't have one yet: + +| Legacy package | Deprecated now, removed at 6.0 | Replacement | +| --- | --- | --- | +| `ember-data` | Yes | `@warp-drive/core` (+ `@warp-drive/ember` for Ember apps, `@warp-drive/legacy` for Model/Adapter/Serializer) | +| `@warp-drive/core-types` | Yes | `@warp-drive/core/types` | +| `@ember-data/store` | Yes | `@warp-drive/core` | +| `@ember-data/graph` | Yes | `@warp-drive/core` (`/graph`) | +| `@ember-data/request` | Yes | `@warp-drive/core/request` | +| `@ember-data/request-utils` | Yes | `@warp-drive/utilities` (`/handlers`, `/string`) | +| `@ember-data/json-api` | Yes | `@warp-drive/json-api` | +| `@ember-data/model` | Yes | `@warp-drive/legacy/model` | +| `@ember-data/adapter` | Yes | `@warp-drive/legacy/adapter` | +| `@ember-data/serializer` | Yes | `@warp-drive/legacy/serializer` | +| `@ember-data/legacy-compat` | Yes | `@warp-drive/legacy/compat` | +| `@ember-data/rest` | Yes | `@warp-drive/utilities/rest` + `@warp-drive/legacy` (`/adapter/rest`, `/serializer/rest`) | +| `@ember-data/active-record` | Yes | `@warp-drive/utilities/active-record` | +| `@ember-data/tracking` | Already deprecated (`DEPRECATE_TRACKING_PACKAGE`, since 5.5, until 6.0) | `@warp-drive/ember/install` | +| `@ember-data/debug` | Yes | the WarpDrive DevTools browser extension ([RFC 0003](./0003-warp-drive-devtools-extension.md)) — not a code change, see "Packages without an import-path replacement" | +| `@ember-data/codemods` | Yes | `@warp-drive/codemods` (new package; a rename, not an absorption — see "Packages without an import-path replacement") | + +`@ember-data/tracking` already has a resolved deprecation story under `DISABLE_7X_DEPRECATIONS`'s +sibling flags and is unaffected by this RFC beyond being folded into the same messaging pass. + +### Deprecation flags + +Three new flags are added to `warp-drive-packages/build-config/src/deprecations.ts`, following +the existing shape (`DEPRECATE_TRACKING_PACKAGE`, `DEPRECATE_EMBER_INFLECTOR`, etc.): + +```ts +/** + * + * + * Deprecates `@warp-drive/core-types`, which has been a pure type re-export + * of `@warp-drive/core/types` since its unification. Import types directly + * from `@warp-drive/core/types` instead. + * + * @since 5.11 + * @until 6.0 + * @public + */ +export const DEPRECATE_CORE_TYPES_PACKAGE: boolean = true; + +/** + * + * + * Deprecates the `ember-data` package and every `@ember-data/*` package + * (`active-record`, `adapter`, `codemods`, `graph`, `json-api`, + * `legacy-compat`, `model`, `request`, `request-utils`, `rest`, + * `serializer`, `store`). Each is either a re-export shim over a + * `@warp-drive/*` package, or (for `codemods`) renamed outright to one; + * import from or install the `@warp-drive/*` package directly instead. + * + * @since 5.11 + * @until 6.0 + * @public + */ +export const DEPRECATE_EMBER_DATA_PACKAGES: boolean = true; + +/** + * + * + * Deprecates `@ember-data/debug`'s ember-inspector integration in favor of + * the WarpDrive DevTools browser extension. Unlike the other flags in this + * group, there is no import to rewrite: uninstall `@ember-data/debug` and + * install the browser extension instead. + * + * @since 5.11 + * @until 6.0 + * @public + */ +export const DEPRECATE_EMBER_DATA_DEBUG_PACKAGE: boolean = true; +``` + +`DEPRECATE_EMBER_DATA_DEBUG_PACKAGE` is split out from the rest because its resolution isn't an +import rewrite — it's a tool swap, so it gets its own message and isn't a candidate for the +`eslint-plugin-warp-drive` autofix described below. The other two flags stay coarse-grained (one +for `core-types`, one for the whole `ember-data` import-rewrite family) rather than one flag per +package, matching how the legacy setup guide already treats the family as a single install +decision ("What about the `ember-data` package?"). A dozen near-identical per-package flags would +multiply the deprecation surface without giving apps a meaningfully different way to resolve +them — the fix is the same import rewrite in every case. + +### Runtime warning + +Each legacy package's shim entrypoint gains a one-time `deprecate()` call, guarded by its flag, +following the same shape as `packages/store/src/index.ts`'s existing +`DEPRECATE_TRACKING_PACKAGE` check: + +```ts +if (DEPRECATE_EMBER_DATA_PACKAGES) { + deprecate( + `Importing from '@ember-data/model' is deprecated. Import from '@warp-drive/legacy/model' ` + + `instead. Enable eslint-plugin-warp-drive's recommended config and run \`eslint --fix\` ` + + `to update your imports automatically.`, + false, + { + id: 'warp-drive.deprecate-ember-data-packages', + until: '6.0.0', + for: 'warp-drive', + since: { enabled: '5.11.0', available: '5.11.0' }, + url: 'https://deprecations.emberjs.com/id/warp-drive.deprecate-ember-data-packages', + } + ); +} +``` + +`@warp-drive/core-types`'s shim gets the equivalent call under `DEPRECATE_CORE_TYPES_PACKAGE` +with `id: 'warp-drive.deprecate-core-types-package'`. `@ember-data/debug` gets its own message +under `DEPRECATE_EMBER_DATA_DEBUG_PACKAGE`, pointing at the extension instead of an import: + +```ts +if (DEPRECATE_EMBER_DATA_DEBUG_PACKAGE) { + deprecate( + `'@ember-data/debug' is deprecated. Uninstall it and install the WarpDrive DevTools ` + + `browser extension instead: https://docs.warp-drive.io/guides/devtools`, + false, + { + id: 'warp-drive.deprecate-ember-data-debug-package', + until: '6.0.0', + for: 'warp-drive', + since: { enabled: '5.11.0', available: '5.11.0' }, + url: 'https://deprecations.emberjs.com/id/warp-drive.deprecate-ember-data-debug-package', + } + ); +} +``` + +All three flags default to `true` (the deprecated behavior is active) exactly like every other +flag in `deprecations.ts`, so opting out early — silencing the warning as soon as it ships — is +not offered; unlike a behavior deprecation, there's no "not yet migrated" code path to keep alive +here, only an import path (or, for `debug`, a tool) to change. + +### npm-level deprecation + +Every legacy package's `package.json` `description` is updated to lead with `(Legacy)` (already +true for `@warp-drive/core-types`; not yet true for the `@ember-data/*` family or `ember-data` +itself), and at the same 5.x minor that ships the flags above, each package's npm registry entry +gets an `npm deprecate` message pointing at the migration guide (see "How we teach this"). This +is metadata only — `npm install` continues to work unchanged for every version published through +the last 5.x release; the notice surfaces immediately in `npm install` output and on the +npmjs.com package page, well ahead of the 6.0 removal. + +### Automated migration + +No new tooling needs to be built for the mechanical import rewrite. `eslint-plugin-warp-drive` +already ships `no-legacy-imports` (`warp-drive/no-legacy-imports`), an autofixable rule enabled +by default in its `recommended` config, driven by a generated, export-level mapping table +(`public-exports-mapping-5.5.enriched.json`) that already covers every re-export-shim package in +the table above — including the `rest`/`active-record` split, since the mapping is per-export, +not per-module (e.g. `import { findRecord } from '@ember-data/rest/request'` already rewrites to +`import { findRecord } from '@warp-drive/utilities/rest'`). Running `eslint --fix` with +`recommended` enabled is the actual migration path this RFC relies on for those packages. The +mapping table gains one more entry for this RFC: `@ember-data/codemods`'s exports routed to +`@warp-drive/codemods`, the same as any other renamed module specifier. + +Two gaps this doesn't cover: + +- The rule only rewrites static `import` declarations. Namespace imports, `export * from` + re-exports, CommonJS `require`, and dynamic `import()` are flagged without an autofix and need + manual migration — worth stating plainly in the migration guide rather than implying + `eslint --fix` alone finishes the job for every app. An app must also already have + `eslint-plugin-warp-drive`'s `recommended` config enabled to get the autofix at all; the + migration guide should call out enabling it as step one for apps that haven't adopted it yet. +- `@ember-data/codemods`'s CLI invocation (`npx @ember-data/codemods ...`) isn't a JS import and + isn't touched by the lint rule; switching it to `npx @warp-drive/codemods ...` is a manual, + one-line change called out in the deprecation message and migration guide. +- `@ember-data/debug` has no autofix at all, covered next. + +### Packages without an import-path replacement + +Two packages' replacements aren't "import from a different specifier," so they don't fit the +re-export-shim story the rest of this RFC relies on: + +- **`@ember-data/debug`** provides the Ember Inspector data adapter. Its replacement is the + WarpDrive DevTools browser extension proposed in + [RFC 0003](./0003-warp-drive-devtools-extension.md) — a different tool entirely, installed in + the browser rather than imported in code. RFC 0003 itself, as drafted, describes the two + coexisting indefinitely ("`@ember-data/debug`'s docs get a note that it remains the + ember-inspector integration for `Model`-based apps"); this RFC instead treats the extension as + `@ember-data/debug`'s full replacement and deprecates the package on the same timeline as + everything else here. That means this RFC's `@ember-data/debug` deprecation is contingent on + RFC 0003 landing — the deprecation message has nothing to point at otherwise. +- **`@ember-data/codemods`** has no `@warp-drive/*` successor today; this RFC creates one by + renaming it to `@warp-drive/codemods` — moving `packages/codemods` under the new name and + leaving `@ember-data/codemods` as a deprecated re-export/CLI shim over it, the same pattern + every other package in the table already follows, just newly created rather than pre-existing. + +### Timeline + +1. **Next 5.x minor:** all three flags ship (default `true`); the runtime warnings and npm + deprecation metadata ship together (the `eslint-plugin-warp-drive` autofix already exists + today, and gains the new `@ember-data/codemods` mapping entry). `@warp-drive/codemods` is + published for the first time, and `ember-data`, every `@ember-data/*` package, and + `@warp-drive/core-types` show a deprecation on install and on first import — `@ember-data/debug` + only once [RFC 0003](./0003-warp-drive-devtools-extension.md)'s extension has landed. +2. **Remaining 5.x betas/minors:** the warning and the `eslint --fix` autofix are the primary + support surface; no further behavior change. This is the entire migration window — it ends at + the next major. +3. **6.0:** WarpDrive stops publishing new versions of the deprecated packages. Versions already + published through the last 5.x release remain installable indefinitely (npm does not support + retracting published versions), so apps that never migrate are not broken outright — they + simply stop receiving fixes, security patches, and compatibility updates for those packages + from 6.0 onward. + +This mirrors the `since <5.x>` / `until 6.0` shape already used by every other active flag in +`deprecations.ts` (`DEPRECATE_TRACKING_PACKAGE`, `DEPRECATE_EMBER_INFLECTOR`, and the rest) — this +RFC's flags resolve on the same release boundary, rather than opening a new post-6.0 deprecation +window the way a behavior flag typically would. The difference from a behavior flag is *what* +"resolving" means: there's no source inside a still-shipping package to delete at 6.0, because the +deprecated thing is the package's own continued publication, not code inside a package that +keeps shipping. The "removal" is that the legacy packages' own releases stop. + +## How we teach this + +- `guides/configuration/legacy-package-setup/index.md` gets a deprecation banner at the top + (the page already carries a "Boilerplate Sucks" callout pointing at RFC 1075; this RFC extends + that callout to state the deprecation is immediate and end-of-publishing lands at 6.0, plainly + and with a date once one is set) and its package-list code blocks get inline notes next to + each deprecated package naming its replacement. +- A new `upgrading/v6/` page (alongside the existing `upgrading/v5/`) documents the full mapping + table from "Detailed design" as the canonical migration reference, plus how to enable + `eslint-plugin-warp-drive`'s `recommended` config and run `eslint --fix`. +- The runtime deprecation message itself (see "Runtime warning") is the primary channel most + developers see this through — it names the exact replacement import and the exact autofix + command, no lookup required. +- This is taught as "finishing package unification," not as a new idea: RFC 1075 is where users + already learned that `@warp-drive/core` is the way forward. This RFC's messaging should link + back to it rather than introduce new terminology. +- `@ember-data/debug`'s deprecation message and migration-guide entry link to RFC 0003's + devtools extension docs, not to an import-path change — it should read plainly as "switch + tools," not as a variant of the same "change this import" instruction every other row gets. + +## Drawbacks + +- **The migration window is short.** Deprecating now with removal at the very next major gives + apps only the remainder of the current 5.x line to migrate, rather than a full major's worth of + beta/minor cycles. Every other flag in `deprecations.ts` gets that same window in principle + (`since 5.x` / `until 6.0`), but most of them were introduced earlier in the 5.x line than this + RFC lands — apps adopting this deprecation late in 5.x genuinely have less time than apps that + picked up, say, `DEPRECATE_TRACKING_PACKAGE` at 5.5. The existing `eslint-plugin-warp-drive` + autofix is not optional polish here; it is load-bearing for apps to make this window — and it + only helps apps that have already adopted the plugin's `recommended` config, which not every + app has. +- **Two of the three flags are coarse-grained** rather than one per package, so an app can't + resolve the deprecation for, say, just `@ember-data/model` while keeping the warning active for + `@ember-data/rest` — it resolves the whole `ember-data` import-rewrite family at once. This + trades precision for a simpler mental model matching how the packages are already documented + and installed. +- **`ember-data` is the simplest onboarding path today** for tutorials and small test apps that + don't want to reason about which of five-to-fourteen packages to install. Deprecating it raises + the bar for a "just try it" first install, unless the unified `@warp-drive/core` install path + is brought to at least the same one-command simplicity before 6.0 ships (tracked by the + existing `@warp-drive/core` setup docs, not by this RFC). +- **6.0 is a lifecycle boundary for two unrelated deprecations at once.** This RFC's packages + finish their deprecation and stop publishing at 6.0; [RFC 0002](./0002-warp-drive-build-plugin.md)'s + babel build path only *begins* its formal deprecation at 6.0 (removed later, at 7.0). An app + reading both at the 6.0 boundary needs to understand it's losing the legacy packages outright + while merely being warned about the babel path — the two migration guides should say this + explicitly rather than let the shared version number imply a shared timeline. +- **`@ember-data/debug`'s deprecation depends on a separate, unlanded RFC.** Tying its removal + to [RFC 0003](./0003-warp-drive-devtools-extension.md) means this RFC's timeline for that one + package is only as solid as RFC 0003's own; if the extension slips, `@ember-data/debug` either + slips with it or ships without a real replacement yet. RFC 0003 as currently drafted also + expects the two tools to coexist rather than one replacing the other — this RFC overrides that + expectation, which RFC 0003 should be updated to reflect rather than have two RFCs disagree. +- **No automatic migration for `@ember-data/debug`.** Unlike every other package here, there's no + `eslint --fix` for "install a browser extension" — apps get a message and a link, not a + mechanical fix, which is a meaningfully worse migration experience than the rest of this RFC. +- **`@warp-drive/codemods` is a new package, not an existing shim.** Every other replacement in + this RFC already exists and is already tested; `@warp-drive/codemods` has to be created + (renamed from `packages/codemods`) as part of landing this RFC, which is real work beyond + "add a deprecation flag" for this one package. + +## Alternatives + +- **Do nothing; keep the legacy packages fully supported indefinitely.** Rejected: it commits + WarpDrive to documenting, testing, and versioning shim code that does nothing but re-export, + forever, with no path to ever simplifying the package graph RFC 1075 was meant to simplify. +- **Remove the legacy packages outright, immediately, with no deprecation period.** Rejected: + skips the standard deprecate-then-remove cycle this codebase already uses for every other + breaking change (see every other flag in `deprecations.ts`), and would break any app that + hasn't migrated with no warning at all. +- **Deprecate at 6.0 and remove at 7.0**, mirroring the timeline this RFC originally proposed and + the one [RFC 0002](./0002-warp-drive-build-plugin.md) uses for the babel build path. Superseded + in this revision: it opens a new post-6.0 deprecation window instead of resolving on the same + `since 5.x` / `until 6.0` boundary every other flag in `deprecations.ts` already uses, and + delays finishing RFC 1075's package unification by a full extra major for packages that have + had a working replacement for some time. +- **Deprecate only `@warp-drive/core-types`, leave the `@ember-data/*` family alone.** Rejected: + every `@ember-data/*` package is the same re-export-shim situation as `core-types`; singling + out `core-types` leaves the larger and more visible part of the problem (the `ember-data` + meta-package and its dependents) unaddressed. +- **Per-package deprecation flags (a dozen-plus flags instead of three).** Considered and + rejected for this RFC in favor of the coarser grouping described in "Deprecation flags" — see + "Drawbacks" for the trade-off this gives up. +- **Build a dedicated `legacy-imports` codemod in `@ember-data/codemods`.** Considered, and + rejected as redundant once `eslint-plugin-warp-drive`'s `no-legacy-imports` rule was found to + already perform the identical autofixable rewrite off a generated, export-level mapping table. + Building a second tool would mean maintaining two mapping tables for the same rename instead + of one. + +## Unresolved questions + +- Whether this RFC's `@ember-data/debug` deprecation should be a normative amendment to RFC + 0003 (updating its "two inspection tools" framing) or stay a standalone claim in this RFC — + and what happens to this RFC's timeline if RFC 0003 isn't ready by the time 6.0 ships. +- Whether apps that haven't adopted the RFC 0003 extension by 6.0 lose `Model`-based + ember-inspector support outright, or whether `@ember-data/debug` needs a short grace period + past 6.0 specifically (unlike every other package in this RFC) to avoid that gap. +- Whether the remaining 5.x window before 6.0 is long enough for apps to migrate given the + existing `eslint-plugin-warp-drive` autofix, or whether this RFC's landing should be gated on + 6.0 being at least a certain number of 5.x minors away at the time it merges. +- Whether the `no-legacy-imports` mapping table (currently named/versioned as + `public-exports-mapping-5.5.enriched.json`) needs a refresh or rename as part of this RFC, and + what should extend it to cover namespace imports, re-exports, and `require`/dynamic `import()` + given those are the one gap in the otherwise-automatic migration path. +- Whether `npm deprecate` notices should be applied to already-published pre-deprecation + versions retroactively, or only to versions published at/after the flags ship. +- Final wording and placement of the `upgrading/v6/` migration page relative to the existing + `upgrading/v5/` content. From ed9505660cb6588c018858e1d7027d0e191ae62d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=F0=9F=A4=96=20WarpDrive=20RFC=20Sync?= <332362369+warpdrive-bot@users.noreply.github.com> Date: Fri, 25 Sep 2026 18:55:13 +0000 Subject: [PATCH 2/2] RFC #1240: fill prs.accepted and rename file with PR number --- ...e-legacy-ember-data-packages-and-warp-drive-core-types.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md => 1240-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md} (99%) diff --git a/text/0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md b/text/1240-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md similarity index 99% rename from text/0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md rename to text/1240-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md index 524731724c..6b2b3cfad1 100644 --- a/text/0000-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md +++ b/text/1240-deprecating-the-legacy-ember-data-packages-and-warp-drive-core-types.md @@ -7,12 +7,12 @@ teams: - data - learning prs: - accepted: + accepted: https://github.com/emberjs/rfcs/pull/1240 project-link: suite: --- -# WarpDrive: Deprecating the Legacy ember-data Packages and @warp-drive/core-types +# Deprecating the Legacy ember-data Packages and @warp-drive/core-types ## Summary