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

Invalid composer.lock when the same requires-dev dependency is present on more than once composer.json #113

Closed
marcoslois opened this issue Apr 18, 2016 · 0 comments
Assignees
Labels
Milestone

Comments

@marcoslois
Copy link

Given two composer.json files, root/composer.json:

{
  "name": "marcos/merget-test",
  "require": {
    "wikimedia/composer-merge-plugin": "~1.3.0"
  },
  "require-dev": {
    "phpunit/phpunit": "^4.8"
  },
  "extra": {
    "merge-plugin": {
      "include": [
        "mods/*/composer.json"
      ]
    }
  }
}

root/mods/test/composer.json:

{
  "name": "marcos/mod-test",
  "require": {
    "monolog/monolog": "^1.19"
  },
  "require-dev": {
    "phpunit/phpunit": "^4.8"
  }
}

When running composer update

Then the composer.lock need to have packages and packages-dev populated.

Error the composer.lock have a packages-dev empty, this causes that development packages get installed when running composer update --no-dev. All the require-dev dependencies are merged, but included in packages instead of packages-dev.

If the requre-dev is only present in one composer.json runs the expected behaviour.

@marcoslois marcoslois changed the title Invalid composer.lock when requires-dev present on more than once composer.json Invalid composer.lock when the same requires-dev dependency is present on more than once composer.json Apr 18, 2016
@bd808 bd808 added the bug label Apr 22, 2016
bd808 added a commit to bd808/composer-merge-plugin that referenced this issue Jul 4, 2016
Composer determines if a given package is a dev mode dependency by
running a solver with dev mode disabled and diffing the result against
the full solver run. This causes every run to two emit
`InstallerEvents::PRE_DEPENDENCIES_SOLVING` events: one with dev mode
enabled and one without. Previously we were using the global dev mode
state set by the main install/update/dump event for both calls. This led
Composer to believe that all conflicting pacakges processed by
composer-merge-plugin were non-dev requirements and an unexpected
composer.lock state for later `composer install --no-dev` executions.

Closes wikimedia#113
@bd808 bd808 self-assigned this Jul 4, 2016
@bd808 bd808 added this to the 1.3.2 milestone Jul 4, 2016
bd808 added a commit to bd808/composer-merge-plugin that referenced this issue Jul 4, 2016
Composer determines if a given package is a dev mode dependency by
running a solver with dev mode disabled and diffing the result against
the full solver run. This causes every run to emit two
`InstallerEvents::PRE_DEPENDENCIES_SOLVING` events: one with dev mode
enabled and one without. Previously we were using the global dev mode
state set by the main install/update/dump event for both calls. This led
Composer to believe that all conflicting pacakges processed by
composer-merge-plugin were non-dev requirements and an unexpected
composer.lock state for later `composer install --no-dev` executions.

Closes wikimedia#113
@bd808 bd808 modified the milestones: 1.4.0, 1.3.2 Jul 11, 2016
bd808 added a commit to bd808/composer-merge-plugin that referenced this issue Jul 11, 2016
Composer determines if a given package is a dev mode dependency by
running a solver with dev mode disabled and diffing the result against
the full solver run. This causes every run to emit two
`InstallerEvents::PRE_DEPENDENCIES_SOLVING` events: one with dev mode
enabled and one without. Previously we were using the global dev mode
state set by the main install/update/dump event for both calls. This led
Composer to believe that all conflicting pacakges processed by
composer-merge-plugin were non-dev requirements and an unexpected
composer.lock state for later `composer install --no-dev` executions.

Closes wikimedia#113
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants