Fix dependecies - #49
Merged
Merged
Conversation
* dev:dependency:find flagged it as unused: no test file has a `use Codeception\Module\Asserts` statement, only the codeception.yml `Asserts` module entry (which the finder doesn't scan for usage). * Already satisfied transitively via codeception/codeception (pulled in through spryker/testify), matching every other Spryker module in the suite - none of them list it directly either.
* codecept build failed after removing codeception/module-asserts from require-dev (previous commit): the module was still enabled in both suites' codeception.yml, and Codeception refuses to build if an enabled module's class isn't installed. * Neither suite actually calls $this->tester->assert*() anywhere - all assertions go through PHPUnit's own $this->assertX() inherited from Codeception\Test\Unit - so the module was dead weight, not a real dependency. Removing it from codeception.yml too (instead of putting codeception/module-asserts back) matches what the code actually uses.
* Fresh installs failed with "php-http/discovery contains a Composer plugin which is blocked by your allow-plugins config" - it's pulled in transitively (HTTP client auto-discovery for the OTLP transport) but was never allow-listed here, unlike the suite root composer.json which already allows it.
* composer.json itself must NOT carry a custom allow-plugins entry - the suite monorepo's dev:composer:update-json-files enforces exactly one entry (dealerdirect/phpcodesniffer-composer-installer) for every Spryker module and strips anything else, which is what happened to the earlier "php-http/discovery": true addition (commit 26fc021). * Standalone CI here still needs the plugin allowed (php-http/discovery is pulled in transitively for the OTLP HTTP transport), so allow it via `composer global config` instead - an ephemeral, CI-only setting that never touches the tracked composer.json.
…config * The previous "composer global config" step was NOT honored by every composer subcommand: the "validation" job's `composer install` picked it up fine, but "prefer-lowest"'s `composer update --prefer-lowest --prefer-stable` still hit the same blocked-plugin fatal despite the identical preceding step (confirmed via the two jobs' CI logs). * Switch to writing the allow-plugins entry into the checked-out composer.json directly (composer config, no --global). Composer always honors its own project-level config for every subcommand. This still never touches the tracked file in the git repo - the CI runner's working copy is discarded after the job, so the entry never gets committed/pushed and never conflicts with the suite monorepo's dev:composer:update-json-files convention.
gechetspr
previously approved these changes
Sep 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Description
Add a meaningful description here that will let us know what you want to fix with this PR or what functionality you want to add.
Steps before you submit a PR
contribution-license-agreement.txtfile with the following content:I hereby agree to Spryker\'s Contribution License Agreement in https://github.com/spryker/opentelemetry/blob/HASH_OF_COMMIT_YOU_ARE_BASING_YOUR_BRANCH_FROM_MASTER_BRANCH/CONTRIBUTING.md.This is a mandatory step to make sure you are aware of the license agreement and agree to it.
HASH_OF_COMMIT_YOU_ARE_BASING_YOUR_BRANCH_FROM_MASTER_BRANCHis a hash of the commit you are basing your branch from the master branch. You can take it from commits list of master branch before you submit a PR.Checklist