Adding plugins to builds (DLLs)

[jodator]

The original story behind this issue can be read in #667. However, some things we discussed in the past may be obsolete today. Hence a new issue that will focus on research & implementation of allowing adding plugins to a compiled builds.

---

Key drivers to have this implemented:

1. Ease of use by external developers.
   • In other words, it should be enable-able just by adding <script> tags of our special build and a bundled (or not) external feature.
2. We should not lose tree-shaking ability in our builds but we're fine with bigger builds that allow adding plugins.
   • However, using the custom build, in that case, is OK.
3. Base editor API should be de-duplicated in such builds.
   • At least enabled once - we can live with double code in that case.
4. Public API should enable most of the integrations possible.
   • Only base editor API is needed, other things should work on top of that.
5. CSS should work and not be duplicated.

We have talked about:

• Explore possible directions:
  • Webpack's module federation API.
  • Webpack's DLL plugin.
  • Exposing CKEditor5 global object (available on window) and dot access to classes (base editor API).
    • it might require better naming for some classes/methods
• Minimizing dependency on the engine, core, and (if possible) UI.
• Deal with CSS de-duplication.
  • Explore ideas from Add CSS styles to classic editor when in a Web Component #7847.
• What modules should expose (as npm package)
  • for instance, every npm package can expose classes as exports in main.js file - this should work well with tree shaking.
  • minimal set of js and css file.
• Conditional attach-to-global. The idea behind this is that feature attaches itself to a global object only if it is empty (so the first attach wins).
• A minimal set of base features to expose is:
  • Engine
  • Core
  • Utils (because of EmitterMixin)
  • UI (might be tricky)
• Resolve EmitterMixing dependency in the utils. Changing Plugin API might a bit might solve that. Check what we import from other features in the first place.
• The main ckeditor5 package could be potentially used to expose the global API.
  • It should be possible to create a build with or without global object (tree shaking, optimizations, etc).

Related issues:

• Introduce Super Build for CDN with all creators and plugins.  #8184 - introduce super build for CDN.
• No default jsDelivr CDN file set #7981 - default jsDelivr CDN file.
• Make ckeditor5 a peer dependency of all other packages #1061 - Make ckeditor5 a peer dependency of all other packages.
• Using CKEditor 5's classes in a code which is transpiled with Babel doesn't work #649 - Using CKEditor 5's classes in a code which is transpiled with Babel doesn't work

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[jodator]

Research summary:

• Review cross-packages imports: Review what's imported in editor's features #8402.
• Webpack's module federation API: Research Webpack's module federation API #8397.
• Webpack's DLL plugin: Research Webpacks DLL plugin #8398.
• Global CKE5 object. Research exposing CKEditor 5 API as a global object #8399.
• CSS de-duplication on multiple imports: Reseach CSS de-duplication on multiple imports #8400.

[jodator]

#667 takeouts:

We should not rely on instanceOf checks in the editor features code. This causes problems when multiple imports occur. OTOH, we should not allow double-imports as only one engine plugin to ensure that all features operate on the same API version (hence, the dreaded ckeditor-duplicated-modules error.

Some ideas from the original issue, namely exposing editor Position, Range & conversion API (#4427, #4428), etc API was already implemented. Newer features are built-in this in mind so the importing from other packages is kept at a minimum... except ui package.

The idea to avoid importing from core (like Plugin or Command) was raised before but during the course of the years, we implemented "disabling API" for those, and we rely on basic plugin & command interface. (#667 (comment), #667 (comment))

Making CKEditor 5 as a peer dependency of all other packages - might be useful for exposing CKE5 global object (#1061, comments below: #667 (comment)).

CKEditor 5 global object (#667 (comment), #667 (comment), #667 (comment))

Duplicated CSS might be a bigger problem (#667 (comment) )

Previous proposal (#667 (comment))

• exposing more API.
• helper or utils (especially pure functions) shouldn't cause duplicated modules erros.
• prevent loading plugin twice should be based on plugin name not the instance

CSS de-duplication ideas: #667 (comment).

[jodator]

#8402: Review cross-packages imports

• Exposing API for cross-packages imports is not feasible ATM.
  • Some features are logical to export while others are used in one-two places as a utility method.
  • The work required to rewrite the features is too big and the ROI might be marginal.
  • We don't know what other developers import.
• It might be worthwile to inpsect which modules or parts of code can't be duplicated and for which it doesn't matter.
  • The EmitterMixin problem.
  • The engine must be on the same level - might be feasible to reduce its usage outsdie.

[jodator]

#8397: It looks like we've missed the biggest premise of the Module Federation - to load code from external entry points at run time. This is a killer feature for micro-frontends but it uses an asynchronous-first approach. AFAICS this might not be feasible to use for sharing a code synchronously. Especially if we want to make it easier to use than we do currently.

[jodator]

#8398: The DLL is very promising and we will go further on this path. The main task for this will #8517 in which we will provide a bunch of DLLs and a way to use them together in a single HTML file as separate <script> tags + one file that ties them together. Something along the lines:

ckeditor5/dll/dll-plugin/index.html

Lines 126 to 149 in 582fbe1

	<script>
	// Sudo import.
	const {
	ClassicEditor, HtmlEmbedEditing, HtmlEmbedUI
	} = window.CKEditor5DLL( './src/index.js' );
	const config = Object.assign( {}, ClassicEditor.defaultConfig, {
	extraPlugins: [
	HtmlEmbedEditing,
	HtmlEmbedUI,
	ComplexBox // exposed by the app.js
	],
	htmlEmbed: {
	showPreviews: false
	}
	} );
	config.toolbar.items.push( 'htmlEmbed' );
	ClassicEditor.create( document.querySelector( '#editor' ), config )
	.then( editor => {
	window.editor = editor;
	} );
	</script>

The const { ClassicEditor, HtmlEmbedEditing, HtmlEmbedUI } = window.CKEditor5DLL( './src/index.js' ); should be resolved by the #8521 - implementing CKEditor 5 global.

[jodator]

After adding more packages to the base DLL and by providing the first DLL consumer plugins (BasicStyles & HtmlEmbed) we have a rather clear path to follow. You can read and track the progress here: #8517 (comment).

There are a few open questions, however, we don't see any clear blocker that would prevent us from delivering the whole thing using DLLs.

[jodator]

Due to the fact that we're in the middle of release and that the work on DLLs might take a bit of time I've introduced the dll-integration branch from current master. Until further notice, all PRs should be merged there.

[jodator]

The base DLL work is done. We've created a dll-integration with all the progress.

ATM you can checkout it and play with it:

1. A dedicate sample was added.
2. To build all DLL plugins and DLL consumers run yarn build:dll in the ckeditor5 main directory.
3. After step 2 build the example DLL consumer plugin in packages/ckeditor5-dll/sample/plugin directory.
4. Open the sample html page in the browser (might require http server).

This is an early build however and still many aspects of this must be polished.

[jodator]

We're implementing some improvements to the DLL build process. This,  unfortunately, means that the dll-integration branch will require using a linked package from @ckeditor/ckeditor5-dev-utils:

1. Clone the git@github.com:ckeditor/ckeditor5-dev.git repository.
2. Checkout the dll-integration branch.
3. Run yarn install.
4. Go to the packages/ckeditor5-dev-utils and link the package using yarn link.
5. Go to ckeditor5 package and use linked package: yarn link @ckeditor/ckeditor5-dev-utils.

[Reinmar]

There's still a long tail of followups, but we can consider DLLs ready to use. Docs will follow soon.