Rfc | Ember.js RFCs
Open on Github

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.

Alternatively, you can also clear the deprecation by moving to Embroider v4 by running the 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. 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?