Closed Dumluregn closed 3 years ago
I don't really remember what was the resolution of our discussion on how we should handle deprecating
divarea
editor type. However, if we would like to follow #130 we should just drop the whole logic responsible for addingdivarea
plugin and throw warring in case of this type, that it's no longer supported and the developer should usedivarea
plugin instead.
I think the conclusion was that we can do #127 easily ("just" clean up warnings) and it's main goal is to have green CI. And #130 is about deprecating/removing diveare
editor type. That was the reason we split it into two task I suppose.
If it turns out that it doesn't make sense to cover #127 separately from #130 we may try to cover both :thinking:
EDIT: This PR now removes the
divarea
editor type instead.Proposed changelog entry (
2.0.0
):This PR contains:- API docs fix (update info thatclassic
editor is the default one, notdivarea
);- tests fix (tests for warning messages were failing);- mechanism addingfloatingspace
plugin to the build if it is inremovePlugins
config and the editor type isinline
(so analogous to thedivarea
editor type) together with unit tests;- some minor refactoring.I'd say there is still some code that could use a refactor (e.g.removePlugin()
method), but it wasn't the subject of this PR so I didn't touch it now.Short note about tests - changing frombeforeEach()
tobeforeAll()
(which was reverting the recent change introduced in https://github.com/ckeditor/ckeditor4-angular/commit/ebf6aed2f7db7866747b8121f50773043e64a2dd) was necessary as the config was changing after it was passed to the component. Now the config is updated properly, i.e. before thedescribe()
block that contains it. And it is separate for each editor type and each config suit, so everything works fine.Closes #130.