🏁 Release: Iteration 5 – 5th developer preview

[Reinmar]

We would like to let you know that the 5th developer preview of CKEditor 5 has just been tagged as version v0.5.0.

You can read about the initial goals of this iteration in #168. While this release did not introduce many end-user features and bug fixes, it brought or began important improvements for the developers and resulted in closing 136 tickets 🎉.

Image feature

As planned, the base image feature landed on master in this iteration. Its development is taking a significant amount of time (it took us already two iterations) because we are concurrently working on the widget system (read about the widgets concept in CKEditor 4 documentation).

So far we have got the following pieces ready:

• rendering,
• selection,
• a part of the keyboard support (deleting),
• clipboard integration.

We are now working on completing the keyboard support and will then work on captioning and alignment.

Note: We are not working on inserting images yet because this is a very integration-specific topic. Most likely, we will propose a general-purpose "insert image" panel with options to drop file, choose from disk, paste a URL and a place to integrate an external JavaScript file browser (like CKFinder). The panel will not have a default behavior, though, as in most of these cases a backend integration is required. Check the image feature UI/UX discussion for more details.

Package: https://github.com/ckeditor/ckeditor5-image

Engine and typing improvements

The following changes were introduced to engine and typing in this iteration:

• Selection's infinite loop check does not kick in too often is now fixed. In this ticket we also worked on destroying the editing controller and views.
• Operational transformation algorithms were stabilized.
• A couple of typing/engine-related bugs were fixed: https://github.com/ckeditor/ckeditor5-engine/issues/633, https://github.com/ckeditor/ckeditor5-autoformat/issues/13, https://github.com/ckeditor/ckeditor5-autoformat/issues/14, https://github.com/ckeditor/ckeditor5-typing/issues/47, https://github.com/ckeditor/ckeditor5-engine/issues/612.

Custom copy/cut support

We added custom copy/cut support for the clipboard feature. It is important to have full control over what gets to the clipboard when dealing with rich content (like e.g. widgets) and browser quirks.

This feature required implementing a generic getSelectedContent() algorithm first.

UI library refactoring

We performed a major review and refactoring of the UI framework and library. It allowed us to significantly simplify the code, shave off a couple of kilobytes and, first of all, improve the developer experience. It is best summarized by these two tickets: https://github.com/ckeditor/ckeditor5-ui/issues/95 and https://github.com/ckeditor/ckeditor5-ui/issues/90.

Testing environment improvements and continuous integration

This was probably the most important change in this iteration. While it had little visible effect, the changes significantly improved our testing and review processes.

First of all, we dropped our custom test runner and switched to Karma + Webpack. It improved the tests performance and general experience when working with bigger pieces of our extensive tests suite that overshadowed less convenient workflow with TDD.

However, the main goal was to simplify the introduction of Travis to all our packages:

Together with each CKEditor 5 package's 100% code coverage (including code branches) and integration with GitHub PRs it speeds up reviews and allows us to maintain the desired quality.

API documentation improvements

Last but not least, we are constantly working on the API documentation. From the beginning we have been thoroughly documenting our code, however, we have not made a definite choice regarding the documentation generator.

In CKEditor 4 we use JSDuck (not to be confused with JSDoc), which is an amazing tool but no longer supported. JSDuck is written in Ruby + ExtJS, which did not allow us to take over this project. Unfortunately, we have not found a JavaScript API documentation generator which would fit our heavy use case well. We have seen that big (really big, not "one pager big") JavaScript libraries either developed their own tools or used bare JSDoc which, unfortunately, by default provides a rather poor experience.

We have tested a couple of API documentation generators and decided to stick to JSDoc, which is still the most mature and extensible solution. We developed a set of JSDoc plugins which allowed us to write CKEditor 5 API documentation in a simpler and more maintainable way. For instance, we added link and type references validation as well as better support for ES6 classes and modules. The results are satisfying enough and we are now reformatting our API docs to the new format. We will share our solution with the JSDoc community once it stabilizes.

Later on, we will also have to work on a more developer-friendly theme (or in fact – an entire page generator) which will close the gap between JSDoc and what JSDuck offers.

Sample

We updated the basic CKEditor 5 sample that you can play with. Check out the developer preview of CKEditor 5 (version 0.5.0) on the CKEditor 5 GitHub.io page.