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

`recompose` doesn't take require-dev into considration #86

Closed
maxime-rainville opened this issue May 27, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@maxime-rainville
Copy link
Contributor

commented May 27, 2018

When running recompose, it ignores dev dependencies.

This can cause issues when your dev dependencies are tied to a specific version of SilverStripe, has recompose will fail when running it's composer update.

Tasks

  • Update the DependencyUpgradeRule interface to define a method that says if a rule should apply to regular dependencies, dev dependencies.
  • Update the DependencyUpgradeRule interface to expect dev-dependencies as well as regular dependencies.
  • Update existing rules to work with new interface definition.
  • Create a new rule based on the Rebuild rule that adds dependencies, but does not do any of the recipe/package substitution. Might be able to abstract common logic in a trait or something.
  • Update ComposerFile::upgrade() to calls dev rules after calling the regular rules .

PRs

@sminnee

This comment has been minimized.

Copy link
Member

commented May 28, 2018

PHPUnit is a notable one here - typically the PHPUnit a project uses should be the same as the PHPUnit SS uses (^4 in SS3 and ^5 in SS4, from memory)

@chillu

This comment has been minimized.

Copy link
Member

commented May 28, 2018

But PHPUnit is only relevant if it's a direct dependency in your own project's composer.json, right? Often times it's indirect via framework, and project code will just use it through SapphireTest. It's still quite common to have dev dependencies with SilverStripe modules, e.g. benmanu/silverstripe-styleguide. So raising the impact to medium, since presumably it's failing hard, and is relatively easy to fix (do the same thing you do for non-dev requirements?)

@maxime-rainville

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2019

Here's I'm thinking of going about this:

  • Update the DependencyUpgradeRule interface to define a a method that says if a rule should apply to regular dependencies, dev dependencies.
  • Update the DependencyUpgradeRule interface to expect dev-depenendencies as well as regular dependencies.
  • Update existing rules to work with new interface definition.
  • Create a new rule based on the Rebuild rule that adds dependencies, but does not do any of the recipe/package substitution. Might be able to abstract common logic in a trait or something.
  • Update ComposerFile::upgrade() to calls dev rules after calling the regular rules.

Unit test should look at some common test packages like phpunit, frameworktest, etc.

We need to find a nice way to lock phpunit to 5.7. Maybe add a conflict clause to framework's composer.json. We could hardcode it, but that might cause us issue down the road if we decide to update our test to work with later phpunit release. We make the condition configurable in .upgrade.yml, but that's kind of subverting composer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.