Use UMD installation method for CKEditor5

I have a proof of concept from last year that successfully does this, and the CK team + several committers were in support of the approach. The biggest part will likely be finalizing #3398525: Add an API for importmaps, after which most of the CK changes are not too intense.

I also created a doc that details the approach and provides steps for several contrib modules on how to approach it

ESM + import map approach gives contrib maintainers the ability to support both types of CKEditor5 builds with a single codebase.

I don't believe the UMD approach can accommodate that, which would mean maintainers having to maintain two separate versions, one that uses imports and the other pulling from the global CKEditor. If there's a way around that - great. If not, then I suppose we need to decide what tradeoffs are acceptable.

I think this is postponed on #3398525: Add an API for importmaps so making that explicit.

Tagging this as a D12 release priority.

Add what this is postponed on to the remaining tasks

Given the urgency here and the complexity of adding import maps, I think we could consider trying to use the UMD build instead, which doesn't require import maps. Initially I thought this wasn't possible to match with our plugin system and contrib, but actually it looks like it might be feasible. It's still going to break BC with existing plugins - they will need to change their build process - but that's unavoidable either way. I know @bnjmnm said that with import maps it should be possible to have a build process that works with both, but we're very close to the deadline now so any solution here is better than no solution.

Switched from DLL to the UMD build. In an Umami install the CKEditor5 instance loads correctly on a node edit page, let's see how the tests get on.

This MR was written and debugged with heavy assistance from Claude Code.

I guess we should deprecate all those stub ckeditor5 libraries now.

The full MR is unreviewable in GitLab because we delete all the individual plugins and translation files, not much I can do about that - try reviewing individual commits.

Added a CR, also assisted by Claude: https://www.drupal.org/node/3581531

Updated the IS and issue title with the new approach.

It's not yet clear if we want to backport this to 11.4 as this will break all CKEditor custom plugins. I guess this should only land in 12.0.0, as long as CKSource can guarantee that they will backport security fixes until the end of life of Drupal 11.

1 test failure:

Drupal\Tests\ckeditor5\Kernel\CKEditor5PluginManagerTest::testEnabledPlugins
Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
     0 => 'ckeditor5/internal.drupal.ckeditor5',
     1 => 'ckeditor5/internal.drupal.ckeditor5.emphasis',
     2 => 'ckeditor5/internal.drupal.ckeditor5.htmlEngine',
-    3 => 'core/ckeditor5.autoformat',
-    4 => 'core/ckeditor5.basic',
-    5 => 'core/ckeditor5.essentials',
-    6 => 'core/ckeditor5.htmlSupport',
-    7 => 'core/ckeditor5.pasteFromOffice',
 ]

core/modules/ckeditor5/tests/src/Kernel/CKEditor5PluginManagerTest.php:1160

Confirmed by Witek Socha in Slack:

yes, DLLs are a part of LTS support, ending in the end of Q3 2028.

In order to not make a breaking change for Drupal 11 contrib modules I think we should land this in Drupal 12, will update the deprecations and change record for that.

We need support until the end of 2028, not Q3, but that is a general mismatch between core's release cycle and CKEditor's LTS, not specific to DLLs.

Doing this in 12.x only seems sensible, except, how do contrib ckeditor5 plugins support both 11.x and 12.x in that case? Would they need to dynamically define the library files based on core version?

What happens to translation support here?

I think contrib modules will have to release a new major, I don't see a way around it.

Translation support seems largely unchanged - similar to the single JS build file instead of each plugin being shipped separately, the translation JS is shipped as a single file per language instead of a file per plugin per language. Assuming we have test coverage for translations then I think we are good, but I haven't manually tested this.

The only test I know of for the actual translations is LanguageTest.php but don't know how comprehensive it is.

#3516264: CKEditor 5 loads all plugin translations on AJAX operations added a bit of coverage for the library level translation mechanism.

MR is green and ready for review. Manual testing and feedback from contrib module authors is very welcome!

Looked over the MR, and code changes make sense generally. Had 1 nit and a question about the use of CKEditor "internal API" (the underscore package exports). Have not manually tested yet.

Also, how does this change the process of linking unminified source for development as documented here: https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckedito...? Though last time I tried, I think I found out painfully that doc might have been out of date already.

I have no idea how to make an unminified build now. yarn build:ckeditor5-dev works for unminified plugins.

It might even be possible to build a simple BC layer and issue deprecation notices so existing DLL plugins will continue to work. Testing something out locally for this.

Added a BC shim with deprecation notice. Proof that it works in the screenshots below; this is https://www.drupal.org/project/ckeditor5_plugin_pack installed on Umami via the lenient plugin. The only change in the module is to set core_version_requirement: ^12.

Not all plugins will necessarily be compatible, I think if they require the function name changes then we might run into issues. But this is definitely a good start!

I was wondering if somehow we could provide a map of the renamed functions, but it is very, very long, even if not everything in the tables was has a different name: https://ckeditor.com/docs/ckeditor5/latest/updating/nim-migration/migrat...

Since I think it's best that we get this in ASAP, I think I'm OK for RTBC on this, but I think it'd be good if we could document how modules with plugins can add BC for the renamed functions.

It would be good to find a contrib module where it's an actual problem and use that as a demo of how to fix it.

I haven't reviewed the MR and am not really qualified to review the js at all anyway. But on getting this in, I think I'd be in favour of something like this:

1. Commit to main as soon as we're happy with it, then it'll be in 12.x alphas once we start releasing those.

2. Talk to contrib ckeditor maintainers, especially ckeditor plugin pack which is maintained by cksource and also has a lot of plugins in it, and ask them to port their modules for Drupal 12 compatibility to test the bc layer.

3. Hold off 11.x commit for now, possibly until 11.4.x is branched so we can commit it only to 11.x, either for backport to 11.4 or an 11.5 release.

We don't need to backport this to 11.x at all, given CKSource have promised us that they will support the LTS version currently in Drupal 11 until it reaches end of life. If the backward compatibility layer turns out to be enough then I guess we can do it if we want to, but if it's at all problematic for contrib I think we should make this change in Drupal 12 only, otherwise it's disruption to D11 users for no gain?

Oh yeah that makes sense. I guess the only thing with that is it wouldn't be possible for contrib modules to drop support for the dll method without also dropping 11.x support, as opposed to when all 11.x branches support umd, but they could still implement webpack in a new branch and drop the old branch when 11.x is EOL.

I pulled the MR branch down locally and tested with https://www.drupal.org/project/ckeditor5_plugin_pack, similar to #31, except with Standard instead of Umami. I tried various plugins such as emoji, word count, page break, font colors and size, and more, and I did not encounter any errors. I think this is good for RTBC.

It would be good to find a contrib module where it's an actual problem and use that as a demo of how to fix it.

I browsed through some contrib modules with CKEditor plugins and didn't find any usage of the moved functions. While this was hardly comprehensive or conclusive, I think we can follow up as the need arises.

Also, how does this change the process of linking unminified source for development as documented here: https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckedito...?

The UMD js comes with a sourcemap, so debugging in the browser inspector can be done with the .ts files. I'm not sure what the process would be if you need to test changes in ckeditor code itself, but this probably will suffice for a lot of use cases. Still probably need a follow up to update https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckedito....

We've also reported our use of underscore functions to the CKEditor team, and we're waiting to hear back, so we should open a follow up on whatever next steps we might need.

I read the comments and updated credit. The only question I see that seems unresolved is what this means for the import maps issue.

We might still want an import maps API to handle other JavaScript imports in a unified way. If we complete that work then we might want to transition CKEditor to use the ESM build instead, but it might not be worth the effort of doing another migration. Therefore to me the issue can stay open but it's no longer blocking this one.

@longwave, thanks for clarifying that point.

CKEditor5 v48 has shipped: https://github.com/ckeditor/ckeditor5/releases/tag/v48.0.0

The DLL installation method is no longer available, so this is the only viable path forward at present to unblock #3587182: Update CKEditor 5 to 48.0.1

Committed and pushed a2b0120864a to main. Thanks!