-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Description
We are proposing a new, standardized policy for how we upgrade the core technologies that CKEditor 5 is built on. The goal is to make it easier for everyone who builds with and contributes to CKEditor 5 to plan for the future.
Our primary goal is to adopt the established best practices of each technology's community. Instead of inventing our own rules, we believe that aligning with well-known standards makes the development process more transparent and easier for plugin authors and projects consuming CKEditor 5. The following proposals are all guided by this principle.
To ensure stability and provide a clear upgrade path for everyone, updates to the following technology targets will be implemented exclusively in major versions of CKEditor 5. This means you will not see breaking changes in tooling or browser support in minor or patch releases.
JavaScript and CSS (Browser Support)
- Impact:
- End-users of the editor
- Projects consuming CKEditor 5
- Plugin authors using CKEditor 5 tooling (Package generator, custom linter rules)
- Internal CKEditor team
- Proposal: Once a year, we will update the build target to align with the "Widely available" category defined by the Baseline web platform standard.
- Why this approach?: Driven by major browser vendors like Google and Mozilla, Baseline provides a clear definition of web features that are mature and safe to use. The “Widely available” category, which we will target, includes features stable across all major browsers for at least 30 months. This approach allows us to balance progress with stability, ensuring CKEditor 5 works for the vast majority of users while leveraging modern web platform features. Its status as a reliable standard is reinforced by growing support from developer tools like MDN, caniuse, Vite, eslint, and Angular.
Note
It’s important to clarify that setting the build target to Baseline "Widely available" does not mean we guarantee compatibility with every browser that technically falls within that window.
Our primary goal is to provide a robust and modern editing experience. If a conflict arises between modern browser behavior and a bug or quirk in an older browser (e.g., related to complex features like typing or selection handling), we will prioritize ensuring correct functionality in modern browsers. This ensures the long-term health and stability of the editor.
TypeScript
- Impact:
- Projects consuming CKEditor 5
- Plugin authors using CKEditor 5 tooling (Package generator, custom linter rules)
- Internal CKEditor team
- Proposal: We will follow the DefinitelyTyped support window. This means the minimum supported TypeScript version will be the oldest version that is less than 2 years old, updated approximately every 6 months.
- Why this approach?: DefinitelyTyped is the de facto standard for TypeScript type definitions (
@types/...
packages) in the entire JavaScript ecosystem. Virtually every typed project relies on it, including CKEditor 5. By mirroring their support policy, we ensure maximum compatibility and interoperability.
Node.js
- Impact:
- Plugin authors using CKEditor 5 tooling (Package generator, custom linter rules)
- Internal CKEditor team
- Proposal: We will update the development environment to the latest Active Long-Term Support (LTS) version of Node.js approximately every 6 months. We may update more often if Node releases critical security fixes that impact development or CI environments.
- Why this approach?: The Node.js community recommends using either Active LTS or Maintenance LTS for production environments. We are choosing Active LTS because it provides the ideal balance for CKEditor 5 tooling: it delivers the high stability and security of an LTS release while giving us access to more modern features than versions in the older Maintenance LTS phase.
Framework integrations (Vue, Angular, React)
- Impact:
- Projects consuming CKEditor 5
- Internal CKEditor team
- Proposal: We will support all officially supported and actively maintained versions of each integration framework. If a library does not publish a clear support window, we will base our decision on usage data, such as community adoption trends and download statistics.
- Why this approach?: Our goal is to ensure that CKEditor 5 integrations are compatible with the versions that most developers are actively using without stretching resources to maintain legacy frameworks that are no longer relevant or safe to use. This strikes a balance between stability and staying current with modern development practices.
What changes can you expect in the near future?
Based on this proposal, here’s what will change (or stay the same) in upcoming releases of CKEditor 5:
- JavaScript – We already target ES2022, which aligns with the current “Widely available” baseline. No changes planned for JavaScript support over the next year.
- CSS – We will introduce tooling to enforce Baseline compliance for CSS features. This means new styles in the codebase will be automatically checked against the “Widely available” baseline to avoid mistakenly introducing unsupported CSS features. No changes planned for CSS support over the next year.
- TypeScript – In the next major release, we will upgrade the minimum supported TypeScript version from 5.0 to 5.3.
- Node.js – We are already using Node.js 22, which is the latest Active LTS version. No major change are needed, but we may increase the minimum required minor version from
>=22
to>=22.18
. - Vue.js – We will drop support for Vue.js 2, which is no longer officially supported.
- Angular – We will drop support for Angular 16, 17, and 18, which are (or soon will be) no longer officially supported.
- React – We will drop support for React 16 and 17, which are no longer widely used.
These changes will take effect in the next major release and will be fully documented in the migration guide.
We want your feedback!
We believe this new policy will provide a clearer, more predictable roadmap for everyone in the CKEditor 5 community. It allows us to evolve the project responsibly while giving you a stable and understandable schedule for future changes.
We welcome your feedback, questions, and concerns on this proposal.