Adjust patches dependencies

Alejandro Cabarcos → made their first commit to this issue’s fork.

Im not sure how we should handle the patches dependency. After reading composer docs and checking other contrib modules, the suggest composer property is used to suggest packages that can improve/boost/help this package.

https://getcomposer.org/doc/04-schema.md#suggest

For example, we could use this property to recommend the Ajax Loader → module, but in this case, we need these patches to be applied.

I think we should provide help so those issues are fixed, and until then, create forks for these modules with the patches applied.

What do you think?

Maybe we should reconsider this with more time, those patches are essential in order to get suite working as expected (removing them may even make some future unit test impossible to pass). Changing MUST to SHOULD to launch first stable version.

The unique point of having them included is that may block some site update due patch does not apply in composer until is adjusted in suite.

I think there 3 options:

1. Add patches to VLSuite's composer.json: installation is automatic and everything works but it will fail when patches are committed upstream
2. Add patches to the README and/or VLSuite module page: installation is not completely automatic but it won't fail because patches are committed upstream.
3. Add patches to VLSuite's composer.json but require specific versions on dependencies, versions we know patches apply: installation is automatic and no error when patches are committed upstream, but we will force VLSuite users to use certain module versions.

Option 3 is nto acceptable if we have to patche the core, we can't force users to use a certain core. WE would have to release a new VLSuite release on each core release.

Option 1 seems handy but it will break in the future.

So I guess the only option is 2. We may use the composer's Drupal Project Message Plugin to display a message about the required patches. Also, we have to list the patches oin the README and in the module's page, ideally with a little explanation on why the patch is needed and for what functionality.

One of the biug drawbacks of option 2 is testing coverage. I thought we could not test anything that require a patch. However, I've just discovered that you can run commands before tests, so we may go with option 2 having complete test coverage.

https://www.drupal.org/drupalorg/docs/drupal-ci/customizing-drupalci-tes... →

The patch in the module conflicts with drupal 10.3.

Thanks @mortona2k, identified patches that does not apply into 10.3.0-beta1:

• "3034979 - Layout builder doesn't support bundle computed field": " https://www.drupal.org/files/issues/2019-02-22/layoutbuilder-bundlecompu... → "
• "3080606 - [PP-1] Reorder Layout Builder sections": " https://www.drupal.org/files/issues/2023-05-30/3080606-100.patch → "

Working on that asap!

3034979 will be replaced by 3045509, created MR & applied into dev version to do some tests.
Other 3080606 is for 3417795 (postponed & not mandatory for stock vlsuite installation).

Re-roll for 10.3.0 of 3080606 (reorder sections core patch) up into that issue

Thanks I was able to install on 10.3 without composer errors.

Release 1.1.7 ready for core 10.3.0 compatibility!

This patch has been merged into Section Library and is no longer needed.

"drupal/section_library": {
    "3217647: Adding stuff to library doesn't close dialog if dialog opens in popup": "https://www.drupal.org/files/issues/2021-06-07/section_library.3217647.close-dialog.2.patch"
}

https://www.drupal.org/project/section_library/issues/3217647 🐛 Adding stuff to library doesn't close dialog if dialog opens in popup RTBC

Great, thanks @mortona2k, minimal required version constraint should be "^1.2", releasing asap!

Integrated changes, another patch down!

2.2.1 Out!