Adjust composer.libraries.json to match webform standards and prevent webform issues

This would be fantastic! Sucks having to have 2 copies of the same library!

So I added the patches and the line to my composer-merge-plugin. Now when I run composer update the libraries are being changed back to link or fakeobjects. Because of the order.

So with the patches they can't find the libraries again because it's looking for ckeditor.link. Should

"extra": {
"installer-name": "ckeditor.link"
},

be added to these modules too?

Take that back that must be added. If it's not and you aren't using webform then this module is now broken because it would be looking for ckeditor.link but this libraries.yml file will load it as link.

@smustgrave that's a great idea, I've added that to the merge request.

Note, it didn't break here, because I've added the installer name config to the root project's composer.json where you have to declare the repository. But still, better doing this at the source.

So still causing issues with me. I think the install-name needs to be in the composer.libraries.json file. If someone calls the anchor_links composer.libraries it will install the libraries under link and fakeobjects.

That's an additional issue maybe, I don't see why and when that should be required. When you use composer install on the root project, it will only look into the composer.json of the module and install the module together with the library. If something was wrong, e.g. the repo not defined in the root composer.json, it won't install the module in the first place.

I don't think that for a composer based workflow, any other scenario could happen. It either installs the module, then the lib gets installed to, or it doesn't.

For a non-composer based workflow - which by all means is no longer recommended - I struggle to see why somebody wanted to use composer for a library installation of a sub-module.

Or is there any other mean to the composer.libraries.json file that I'm missing?

If you add
"merge-plugin": {
"include": [
"web/modules/contrib/webform/composer.libraries.json",
"web/modules/contrib/anchor_link/composer.libraries.json"
]
},

It will pull the libraries in the wrong directories. If I clear my root/libraries folder and do a fresh install it still doesn't pull in the right. Same if I delete the anchor_link module and run composer install. I believe this approach is saying you shouldn't use composer.libraries and that using it could break the module.

The merge plugin got abandoned from Drupal core quite a while ago. We still "liked" it and wanted to continue using it, but since it doesn't support Composer 2, we've had to remove it completely. And TBH, the issues it causes have been much bigger than its benefits. So, I wouldn't recommend using it any longer, but of course if the maintainers of this module want to continue maintaining the composer.libraries.json file, it is pretty easy to add that extra line there too.

So composer merge plugin 2.0.x does work with Composer 2 now.

And this ticket seemed to be about getting other modules to follow the standard that webform appears to be using with the ckeditor. prefix. They add their installer-name in the composer.libraries file and not composer.json. So that's kind of why I think it should be moved here to match. So everything is following the same pattern and working together.

Here's a patch that if you call composer.libraries it will load the libraries into ckeditor.link and ckeditor.fakeobjects.

Oops wrong file

@smustgrave adding your extra changes to the MR might be easier for the maintainers to review and eventually merge.

A slight improvement on whitespace in composer.libraries.json. I also updated the MR with the changes from #16.

I think the solution suggested by #3118314: drupal-ckeditor-libraries-group composer installation support is easier which doesn't require any modification to the root composer.json file.

Having looked through it, I think it'd be worth supporting the library from both locations, but that the module should default to reusing the same path as Webform uses.

Changing the status back to "needs work" as both paths should be supported.

Re-roll of #19 from above against 8.x-2.x-dev.
8.x-2.6 just released a few days ago, so patch was incompatible. Also took care of a couple typos while I was in there.

I agree with #22 that ideally both would be supported in some capacity!

I agree with #22 too
Testing the changes

To be honest, it makes no sense that this module is providing the library for CKEditor FakeObjects. The composer json of this module should restrict itself to the ckeditor.link plugin, since that is the one it uses directly, even if the fakeobjects plugin must also be installed somehow, but that should be handled by that module. See #3208959: Store plugin in libraries/ckeditor.fakeobjects.

@jcnventura is this maybe worth a separate issue? I mean, the fakeobject has been in the code base also before this discussion about the library location started, which is what this issue is about, isn't it?

Tweak to the patch in #23

Missed one instance of link > ckeditor.link which was causing the library to be found in the filesystem at the new location, but was still reporting the original location.

Indeed, totally agree with @jurgenhaas on #26.

In the meantime, tested #27 and all seems working as expected.

Bumping. Still works in conjunction with #3208959: Store plugin in libraries/ckeditor.fakeobjects

Starting with Webform 6.2.0, the Webform module is no longer offering their own version of CKEditor but has switched to core's editor. This was done so they could support both CKEditor 4 and 5 without having to maintain their own custom versions of both. They have now switched to offering their own editor profiles instead. For more info see #3322552: CKEditor 5 support.

That means changing the install paths to match Webform's naming scheme is not a good idea any more, since these are only used in Webform 6.1.x which will be obsolete in 2 weeks when Drupal 9 support is dropped.

I propose to close this as "Won't fix".