Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add symfony 7 support to vendor-plugin and recipe-plugin #325

Open
4 tasks
emteknetnz opened this issue Oct 24, 2024 · 5 comments
Open
4 tasks

Add symfony 7 support to vendor-plugin and recipe-plugin #325

emteknetnz opened this issue Oct 24, 2024 · 5 comments

Comments

@emteknetnz
Copy link
Member

emteknetnz commented Oct 24, 2024

silverstripe/vendor-plugin:^2 and silverstripe/recipe-plugin:^2 both have some method signatures that assume symfony 6 is being used

CMS 6 uses symfony 7 and there don't appear to be any issues with this in the CI builds for CMS 6. However we've had community feedback that there are issues is some circumstances with this in this issue and this issue.

It probably makes sense to release v3 versions for both of these modules to be released that have method signatures updated to match symfony 7, and to update any CMS 6 modules that use these modules accordingly

Related issues

Acceptance criteria

  • New major version of silverstripe/recipe-plugin and silverstripe/vendor-plugin are released
  • Method signatures are updated to match those in symfony 7
  • CMS 6 supported modules that use either of these dependencies are updated from ^2 to ^3
  • CMS 5 modules remain on ^2
@GuySartorelli
Copy link
Member

GuySartorelli commented Oct 24, 2024

CMS 5 modules remain on ^2

Given this seems to be about what version of the symfony library is used in composer, it might be sensible for us to have a ^2|^3 constraint for CMS 5. That way it will be forward compatible with later composer versions.

@emteknetnz
Copy link
Member Author

I'd like to avoid dual support as it caused a lot of maintenance problems in CMS 4.

The "used in composer" part of this I'm finding fairly confusing. I'm making the assumption here that composer means the composer/composer dependency that's installed with silverstripe i.e. in a CMS 6 kitchen-sink installed e.g. composer show | grep composer/composer will show 2.8.1 on my local.

I don't think ^2|^3 for CMS 5 makes any sense? What good would the ^3 do for say silverstripe/vendor-plugin (required by silverstripe/framework)? CMS 5 requires symfony 6. If silverstripe/vendor-plugin:^3 is type hinted for symfony 7, then won't that then cause an issue since it's being installed with symfony 6?

@GuySartorelli
Copy link
Member

GuySartorelli commented Oct 24, 2024

I'm making the assumption here that composer means the composer/composer dependency that's installed with silverstripe

No, I mean literally composer, as in when you run composer require silverstripe/framework. Composer is a PHP project that has PHP dependencies. The plugins plug into composer, so they need to be compatible with its PHP dependencies.

@GuySartorelli
Copy link
Member

I don't think ^2|^3 for CMS 5 makes any sense? What good would the ^3 do for say silverstripe/vendor-plugin (required by silverstripe/framework)? CMS 5 requires symfony 6. If silverstripe/vendor-plugin:^3 is type hinted for symfony 7, then won't that then cause an issue since it's being installed with symfony 6?

The dependencies required by silverstripe's various modules are entirely irrelevant. The plugin needs to be compatible with the dependencies that the installed version of composer on the user's host machine is using when they run composer vendor-expose or composer require, etc.

@emteknetnz
Copy link
Member Author

emteknetnz commented Oct 24, 2024

The plugin needs to be compatible with the dependencies that the installed version of composer on the user's host machine is using when they run composer vendor-expose or composer require, etc.

Well, it's certainly a confusing topic

My understanding is that composer is installed as a downloaded phar which is over 100K lines long and has all its own composer dependencies i.e. the entire vendor folder "baked in". So that's what the dependencies on the host machine that composer is using are?

My local is running PHP 8.1 (for CMS 5 compatibility) and composer 2.8.1, when I installed composer did I get a version with symfony 6 support? Or symfony 7 support? Did I simply download the pre-baked composer.phar hosted on the 2.8.1 release page? Or does I get a dynamically generated one based on my local environment? Symfony 7 requires PHP 8.2. I can run composer vendor-expose on a CMS 6 project with no issues

In CI we're using shivammathur/setup-php which will happily install PHP 8.3 with symfony 7 for Silverstripe modules and run a bunch composer commands and the dev/build with no issue

If what you're saying is correct about "The plugin needs to be compatible with the dependencies that the installed version of composer on the user's host machine" - it seems that putting ^2|^3 for silverstripe/vendor-plugin in silverstripe/framework's composer.json will only take into account what silverstripe/framework wants, not what the composer on the host machine wants?

@GuySartorelli GuySartorelli added this to the Silverstripe CMS 6.0 milestone Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants