Affect plugins loading order without creating strict requirements

[pjasiun]

We already touched this topic here, but it was not implemented then.

Currently, when one plugin requires another plugin you can be sure about two things:

• the required plugin will be loaded,
• the required plugin will be loaded before your plugin.

However, sometimes we need only the second part. Another plugin is not necessary, but if it is loaded we want it to be initialized before our plugin. Currently afterInit needs to be used what is far from a perfect solution. My proposal is to introduce soft requirements:

class A extends Plugin {
	static get softRequires() {
		return [ 'B' ];
	}

	static get pluginName() {
		return 'A';
	}

	init() {
		if( this.editor.plugins.has( 'B' ) {
			console.log( 'B is also loaded!' );
		}
	}
}

class B extends Plugin {
	static get pluginName() {
		return 'B';
	}
}

It means that if the plugin B is not loaded then plugin A shows no errors nor warnings. However, if plugin B is loaded, then it is initialized before plugin A, the same way, as it would be a requirement.

Note, that I am not sure about "Soft requirements" name nor about softRequires method name. Feel free to propose a better name.

[Reinmar]

Yeah, I think I discussed this recently with someone. A different option appeared, AFAIR, but in general, the same concept. So 👍 for doing this.

I think the other option could be to have all in the requires() section but some plugins would be defined by name (string == soft) and some by class (function == hard). But I think that a more descriptive softRequires() is actually better.

[Reinmar]

OK, @pjasiun reminded me that in https://github.com/ckeditor/ckeditor5-core/issues/148 we already added "by name" support in requires(). I completely forgot about that 😃

So, I'm actually hesitating now. If the order of plugins is the only problem here, then until we really see a need for something more I'd use afterInit(). So far it worked well – all code which registers something goes to init() and all which uses the information about registered "things" to afterInit().

Of course, this mechanism must not be abused because you can create chains of "do X if Y", "do Y if Z", etc., but this is usually easy – you can postpone making decisions how your feature should behave to later stages (e.g. command's refresh logic) and then you completely untangle two features.

Also, a completely extreme version of a chain is a loop of requirements and even soft requires would not be a solution here. You need to make reasonable decisions when implementing relations between features.

Finally, I think that the "soft requirement" mechanism has a very narrow application – only to cases where a dependent plugin knows precisely with which other plugins it should work. In most cases this isn't true – e.g. Autoformat should not assume that it needs Bold because the bold functionality could be provided by 3rdPartyBold. Actually, people usually prefix their extensions, so this is a real case.

So, let's wait for a clear signal that we miss something.

[Reinmar]

Plot twist: I've been analysing https://github.com/ckeditor/ckeditor5-core/issues/148 and I was right by thinking we don't support string requirements. This ticket didn't actually introduce them :D

I'll create a new ticket for that concept.

[Reinmar]

Another plot twist: I proposed to get rid of soft requirements (in the sense we used them in the past) completely to acknowledge the current state of things: https://github.com/ckeditor/ckeditor5-core/issues/193.

[jodator]

Read like a good novel with so much plot twists :D

[jodator]

Ha! Another plot twist. We will probably have to loosen some requires() calls due to work on CKEditor5 DLL (#8395). What we will need here:

• Probably new method alongside requries() that will define softRequires() - I'm unsure about the naming but let leave it as is for now.
• The softRequires() should be used to cross-package requirements definition.
• The requires() should be left as now for "glue" packages as an automatic plugin loading mechanism for plugins from the same package. In most cases, it would be that Feature will require FeatureEditing and FeatureUI.

[jodator]

Again, the same finding as before IIRC:

• The Plugin.requires() can have string. It will try to load a plugin from builtinPlugins (the availablePlugins in PluginCollection.
• I've modified a bit plugin loading to also allow loading plugins from plugins object (so re-ordering them).
• If a plugin is unavailable (either builtinPlugins or plugins array) we can reject editor loading (right now it doesn fail).

Last changes: https://github.com/ckeditor/ckeditor5/compare/dll-integration...i/2907?expand=1

[jodator]

After a F2F talk, we agreed that there's no need to introduce new softRequires getter as we already allow a string to be specified there. The current behavior will be expanded to order plugins available either as Editor.builtinPlugins or plugins / extraPlugins configuration option. ATM, the string only loads a plugin if it is defined in builtinPlugins.

[pomek]

Closed with 9c24fca.