globalThis.CKEDITOR_VERSION possibly out of date?

[babielgy]

📝 Ask a question

Hey, while debugging some of my ckeditor-duplicated-modules errors, I came to the origin of it: version.ts

The global check of globalThis.CKEDITOR_VERSION prevents different CKEditor builds to be loaded on the same page, which in some cases, is actually the wanted outcome.

Which can be understandable if this was a way to prevent conflicts in old releases. In reality, the ckeditor builds are encapsulated in itself, so conflicts are unlikely to happen, because the loaded classes are not global.

Which makes me wonder:

• is there a more technical reason for this check nowadays? Runtime errors are less likely to happen, because of encapsulation
• can the global check of this constant be removed?
• shouldn't the CKEditor Version be better written as a data attribute to the editor element itself, or as a getter in the editor instance?

[Reinmar]

The global check of globalThis.CKEDITOR_VERSION prevents different CKEditor builds to be loaded on the same page, which in some cases, is actually the wanted outcome.

Could you elaborate on this? I mean: when do you want to load two different versions of CKEditor?

I'm asking because this is, I think, the first time that I hear that someone actually wants two different versions :)

The origin of this check is not exactly related to loading two different versions of CKEditor. It prevented building CKEditor from source with conflicting versions of dependencies, which in turn caused duplication of several packages down the dependency chain. This, caused the editor to malfunction because a single editor instance suddenly had to deal with instances of objects coming from e.g. two ckeditor5-engine packages.

Until mid-2024 the main distribution method of CKEditor was via its uncompiled source, so a large percentage of integrators were installing the 100+ packages of CKEditor 5 separately. Then, they were building CKEditor from source to integrate it. One tiny version conflict between these packages (and we learned the hard way that with npm/yarn/pnpm and 3rd party packages and the package locks, there were plenty of options to end up there) were resulting in duplicated packages. This check was meant to surface this issue to the integrator, helping to channel their attention to those facts.

Now, since mid-2024 things have changed (see #15502). The default distribution method now is an all-bundled CKEditor 5. Does it prevent situations where CKEditor modules can be duplicated? Yes, but not entirely. We can observe this in traffic to that particular error page in the docs – it dropped by 50%, but the traffic is still there.

How can one trigger it now?

• Building from source is still supported (will be till the end of 2025).
• Building from separate packages (as opposed to using ckeditor5 only) is still supported and we plan to support this method.
• One can include a 3rd party addon in a conflicting version (making npm install its dependencies separately)
• On top of that: one can mix snippets from the new installation method with old ones.
• Or use an outdated 3rd party addon that relied on old installation methods and mixes types of imports.
• and so on...

The check still helps to surface those situations. And I'm afraid it cannot go away, even long after we completely sunset old installation methods.

Furthermore, we cannot guarantee now that a duplicated editor codebase would actually work. We're not testing CKEditor for that and I can imagine nasty issues stemming from this. While the modules/classes/etc might be isolated, they work in a single DOM structure, in a single window/document. So they will interact, and no one can predict now what happens then. Also, AFAIR, we still use a global object to store translations. Those issues, could, of course be ironed out, but under a cost that might be really hard to justify.

[Reinmar]

We had a brief chat about this in the team. Some notes:

• One idea that we had in the past, was to move the version validation to plugins.
  • This would allow logging more specific information (which plugin is incompatible), as opposed to the current generic error
  • This would need to support the version ranges, so 3rd party plugins can define that they are compatible with e.g. v44+.
  • Though, would this detect the situations where different types of imports are used? Unfortunately, not :(
• The global version is useful when debugging integrations. It lets the integrator/support team to quickly understand which version is used, even if not very tech-savvy person is doing this.

[babielgy]

Hey @Reinmar, thank you for the fast and detailed response. Definitely a lot of insights that I wasn't aware of.

In my case, what I'm doing is reloading the CKEditor instance on runtime. That's how I come across "two different versions" on the same page. Basically loading a new version of the build and then destroying the old editor so I can initialize it again, but with the new code from the new compiled bundle.
The code to create the editor is exposed in a global variable named CKEDITOR5 which is being replaced every time we load the new bundle. It exposes few functions which create different ClassicEditors with different configurations.

This can have some advantages when we want to deploy our application without downtime, as we can load the new bundle from external source and then refreshing the editor without the need to reload the window.

The biggest advantage comes from the developer point of view - we can develop our plugins with in the sample-environment described in the official docs and then test them much easier in the End-System where we deploy our bundled CKEditor, without having the need to recompile everything for small changes.

It has solely development reasons right now. Because we are able to refresh the instance with the new code, we were able to develop and test much easier in the target end system.

The only way we could do that was to run delete window.CKEDITOR_VERSION; before we load the new bundle in order to load the new bundle without errors.

As this procedure is currently only used in our local development environment, we accept potential side-effects, although we couldn't find any yet. That's why I was wondering about this constant in general.