Implement DLLs for CKEditor 5 features #8517
Comments
jodator
added
type:feature
|
OH, I've just stumbled on first obstacle, that might be hard to overcome in a granular approach. It looks like intermediate DLL is not possible. So it's either a DLL or a DLL consumer. If I cannot overcome this issue, I'll probably make a shortlist of CKEditor plugins that need to be in every build. |
|
At this stage, using top-level webpack's plugins for DLLs I don't see that we could implement options 0-3. Problem 1: No DLL in other DLLThe reason for this is that in one webpack config there can be either From this point I can see that we could:
ATM, I'm leaning towards one super DLL with (more on cross-package dependencies in #8402):
Optionally, we should investigate whether cross-packages imports makes sense for:
All other packages might be created as a DLL consumer and be exposed as UMD build (or just global). Problem 2: imports in DLL consumerThe other thing that I've discovered is (a similar issue was raised by @pomek) that writing code imports for DLL is different than for our own code. This is probably easier to solve with a custom plugin. The thing is that it that I would like to remain imports in sync with the paths in packages (might require For instance, if our end-plugin would have imports: import Plugin from '@ckeditor/ckeditor5-core';
import EmitterMixin from '@ckeditor/ckeditor5-utils';It should be picked up by webpack in DLL consumer mode as (Those are already available in my DLL POC): import Plugin from '@ckeditor/ckeditor5-dll/core';
import EmitterMixin from '@ckeditor/ckeditor5-dll/utils';It looks like a simple string replacement before the DLLReferencePlugin would do its magic. I've tried to:
|
|
Recent findings on how the DLL builds work:
This proves the POC but still requires work to have a sane development environment. This is because I couldn't find a way to use import { Plugin } from '@ckeditor/ckeditor5-core/index' // or without index
import { ButtonView } from '@ckeditor/ckeditor5-ui/index'ATM I can use import { Plugin } from '@ckeditor/ckeditor5-core/core'
import { ButtonView } from '@ckeditor/ckeditor5-ui/ui'because those are just the same as (notice the import { Plugin } from '@ckeditor/ckeditor5-dll/core'
import { ButtonView } from '@ckeditor/ckeditor5-dll/ui' |
|
Thanks to the @pomek's work on the CKEdtior 5 global I've added a Basic Styles feature as a DLL consumer. What I was able to achieve is this: <!-- This adds the CKEditor5_DLL in the global scope, so it is possible to reference its contents -->
<script src="../build/ckeditor5-dll.js"></script>
<!-- This is a stripped-down ClassicEditor with Essentials plugins loaded from a DLL, exposed as ClassicEditor -->
<script src="../../ckeditor5-dll-classic/build/dll-classic.js"></script>
<!-- Editor features as DLL consumer builds exposed as CKEditor5[FeatureName] -->
<script src="../../ckeditor5-basic-styles/build/basic-styles.js"></script>
<!-- Finally, this is a end-user plugin that uses DLL -->
<script src="../build/dll-consumer-plugin.js"></script>
<script>
// Import Bold, Italic from the CKEditor 5 global.
const { Bold, Italic } = CKEditor5.BasicStyles;
const config = {
extraPlugins: [
Bold,
Italic,
DLLConsumerPlugin // exposed by the dll-consumer-plugin.js
],
toolbar: [
'bold',
'italic',
'|',
'a-button',
'|',
'undo',
'redo'
]
};
// ClassicEditor is exposed by the ckeditor5-dll-classic:
ClassicEditor.create( document.querySelector( '#editor' ), config )
.then( editor => {
window.editor = editor;
} );
</script>Despite some nuances regarding the need to rewrite inter-package imports in DLL consumer plugins, this looks kinda awesome. Right now a manual work will be needed to align all the features to DLL approach as additional boilerplate code needs to be written. However, after the initial work, we should not modify them too often. Edit: This is mostly due to cross-packages imports: #8402 (comment). |
|
And two editor DLL builds (Classic + Inline) on the same page: <!-- This adds the CKEditor5_DLL in the global scope, so it is possible to reference its contents -->
<script src="../build/ckeditor5-dll.js"></script>
<!-- Those are stripped-down editors with Essentials plugins loaded from a DLL, exposed on CKEditor global -->
<script src="../../ckeditor5-dll-classic/build/dll-classic.js"></script>
<script src="../../ckeditor5-dll-inline/build/dll-inline.js"></script>
<!-- Editor features as DLL consumer builds exposed as CKEditor5[FeatureName] -->
<script src="../../ckeditor5-basic-styles/build/basic-styles.js"></script>
<!-- Finally, this is a end-user plugin that uses DLL -->
<script src="../build/dll-consumer-plugin.js"></script>
<script>
// Import Bold, Italic from the CKEditor 5 global.
const { Bold, Italic } = CKEditor5.BasicStyles;
const { ClassicEditor, InlineEditor } = CKEditor5;
const config = {
extraPlugins: [
Bold,
Italic,
DLLConsumerPlugin // exposed by the dll-consumer-plugin.js
],
toolbar: [
'bold',
'italic',
'|',
'a-button',
'|',
'undo',
'redo'
]
};
// ClassicEditor is exposed by the ckeditor5-dll-classic:
ClassicEditor.create( document.querySelector( '#editor-classic' ), config )
.then( editor => {
window.editor = editor;
CKEditorInspector.attach( { 'dll-classic': editor } );
} );
// InlineEditor is exposed by the ckeditor5-dll-inline:
InlineEditor.create( document.querySelector( '#editor-inline' ), config )
.then( editor => {
window.editor = editor;
CKEditorInspector.attach( { 'dll-inline': editor } );
} );
</script> |
DLL system plan of actionBelow are most of the changes required to create CKEditor 5 DLL system. There are 2 components of this:
Packages to include in base DLLThis set of packages will shape the size and features available. Either those are required packages by the editor or are functionalities that will end up in 80% of the editors.
The public-public API, defined as anything that must be imported by other packages, should be defined in main The base editor packages are in the DLL build because those are intermediate packages. Those are using DLL packages and expose themselves as a base editor classes. The DLL system does not allow it explicitly so those must land in base DLL to reduce code duplication. The editor builds are provided as other plugins and will be exposed on CKEditor5 global (e.g. New packagesThe outcome of this will be new packages, although maybe we could expose DLL builds from the build packages to reduce overhead.
Packages that are used during the buildThis package(s) are used by DLL build and changes in them are not needed ATM.
Packages to be provided as DLL-consumer
Alternatives to DLL (no action)I don't see a need for essentials ATM as it is a shortcut plugin for the standard builds.
Open questions:
|
|
Ad 2.: I've tried to use |
|
How to debug DLL imports (if everytihng is OK) in case you get "duplicated" module errors.
Example output: The culprit in Image files was a left over: import { enablePlaceholder } from '@ckeditor/ckeditor5-engine/src/view/placeholder';
import { toWidgetEditable } from '@ckeditor/ckeditor5-widget/src/utils';Which should be: import { enablePlaceholder } from '@ckeditor/ckeditor5-engine/engine';
import { toWidgetEditable } from '@ckeditor/ckeditor5-widget/widget';A proper entry should be: |
|
The initial DLL build is done. We have a working DLL sample with 4 different editor "builds" and a few plugins: basic styles, image and html embed. 🎉 . |
Feature: Introduce the CKEditor 5 DLL build. Closes #8517.
|
Closed by |
📝 Provide a description of the new feature
As the DLL spike research proved the approach, we will implement the DLLs for the CKEditor 5 as multiple DLLs.
During F2F talks with @Reinmar & @pomek, we've identified that implementing DLLs might be created on multiple levels to provide reuse of core CKEditor packages and to minimize, if possible, the number of
<script>tags needed to insert into the document. To do that, we would choose among below 3 options:1st option:
ckeditor5@ckeditor/ckeditor5-editor-*@ckeditor/ckeditor5-*2nd option:
ckeditor5@ckeditor/ckeditor5-editor-*@ckeditor/ckeditor5-*3rd option:
Potential issues:
Additionally, I see option 0: every package is a DLL.
If you'd like to see this feature implemented, add a 👍 reaction to this post.
The text was updated successfully, but these errors were encountered: