diff --git a/text/1101-deprecate-ember-vendor-bundles.md b/text/1101-deprecate-ember-vendor-bundles.md new file mode 100644 index 0000000000..1fe72597cd --- /dev/null +++ b/text/1101-deprecate-ember-vendor-bundles.md @@ -0,0 +1,155 @@ +--- +stage: accepted +start-date: 2025-05-13T00:00:00.000Z +release-date: # In format YYYY-MM-DDT00:00:00.000Z +release-versions: +teams: # delete teams that aren't relevant + - cli + - framework + - learning +prs: + accepted: https://github.com/emberjs/rfcs/pull/1101 +project-link: +suite: +--- + + + + + +# Deprecate Ember Vendor Bundles + +## Summary + +The published `ember-source` package contains several AMD-specific bundled builds +of Ember that are appended to `vendor.js` in the classic build system. +This RFC deprecates the following files: + +- `ember.debug.js` +- `ember.prod.js` +- `ember-testing.js` +- `ember-template-compiler.js` + +Instead, Ember will be included in application builds as ES module library via `ember-auto-import`. + +## Motivation + +Maintaining the legacy AMD-specific bundled copies of Ember is no longer necessary. +Modern Ember applications should consume Ember as ES modules, which aligns with +the broader JavaScript ecosystem. This change simplifies the build pipeline and +reduces maintenance overhead. + +This deprecation will have no effect on applications using Embroider with +`staticEmberSource: true` or Embroider v4 (Vite). It only impacts applications +using the classic build system without Embroider. + +## Transition Path + +> This is the bulk of the RFC. + +> Explain the design in enough detail for somebody +> familiar with the framework to understand, and for somebody familiar with the +> implementation to implement. This should get into specifics and corner-cases, +> and include examples of how the feature is used. Any new terminology should be +> defined here. + +> Please keep in mind any implications within the Ember ecosystem, such as: +> +> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed +> - Features that are replaced or made obsolete by this feature and should eventually be deprecated +> - Ember Inspector and debuggability +> - Server-side Rendering +> - Ember Engines +> - The Addon Ecosystem +> - IDE Support +> - Blueprints that should be added or modified + + +### Classic Build System + +We will introduce a new optional feature for projects to opt into consuming +Ember as ES modules. Not having this optional feature enabled will result in +a deprecation warning. + +Addons that rely on accessing Ember from `treeForVendor` or on accessing Ember +from vendor will need to update their implementation. + +### Embroider v4 or with `staticEmberSource: true` + +This deprecation will have no effect on these projects. They already consume Ember as ES modules. + +## How we teach this + +> What names and terminology work best for these concepts and why? How is this +> idea best presented? As a continuation of existing Ember patterns, or as a +> wholly new one? + +> Would the acceptance of this proposal mean the Ember guides must be +> re-organized or altered? Does it change how Ember is taught to new users +> at any level? + +> How should this feature be introduced and taught to existing Ember +> users? + +> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc. + +### Deprecation Guide + +Ember will no longer publish legacy AMD-specific Ember builds. To opt-in to +consuming Ember as ES modules and clear this deprecation, enable the +`ember-modules` optional feature by running `ember feature:enable ember-modules`. + +This applies only to the classic build system or to Embroider < 4.0 without the +`staticEmberSource: true` option. If you see this deprecation warning in these +setups, please [open an issue](https://github.com/emberjs/ember.js/issues/new/choose). + +Alternatively, you can also clear the deprecation by moving to Embroider v4 by +running the [Ember Vite Codemod](https://github.com/mainmatter/ember-vite-codemod), +but this may require additional changes to your project. + +The AMD-specific Ember builds will no longer be published in next Ember major release +and no longer be bundled into `vendor.js`, even on the classic build system. These files are: +- +- `ember.debug.js` +- `ember.prod.js` +- `ember-testing.js` +- `ember-template-compiler.js` + +- In rare cases, Addons were relying on accessing Ember from `vendor`. If you have +addons that do so they will need to be updated to consume Ember as ES modules. + +A known addon that previously relied on accessing Ember from `vendor` is +[ember-cli-deprecation-workflow](https://github.com/ember-cli/ember-cli-deprecation-workflow). +Please ensure you are on the latest version of this addon as that reliance has +been removed. + +## Drawbacks + +> Why should we _not_ do this? Please consider the impact on teaching Ember, +> on the integration of this feature with other existing and planned features, +> on the impact of the API churn on existing apps, etc. + +> There are tradeoffs to choosing any path, please attempt to identify them here. + +## Alternatives + +> What other designs have been considered? What is the impact of not doing this? + +> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. + +## Unresolved questions + +> Optional, but suggested for first drafts. What parts of the design are still +> TBD?