spryker-sdk/composer-constrainer

ComposerConstrainer module

0.2.7 2023-12-13 08:54 UTC

Requires

• php: >=7.4
• roave/better-reflection: ^5.0.0 || ^6.0.0
• spryker/kernel: ^3.33.0
• spryker/laminas: ^1.0.0
• spryker/symfony: ^3.2.2
• spryker/transfer: ^3.27.0

Requires (Dev)

• codeception/module-asserts: ^1.3
• ergebnis/json-printer: ^3.1
• phpstan/phpstan: ^1.2.0
• spryker/code-sniffer: *
• spryker/console: *
• spryker/testify: ^3.15.0

proprietary

README

Tool to detect extended core modules and to update composer.json constraints from using ^ (caret) to using ~ (tilde) for those extended modules.

What will be found by this tool

• Extended API and non-API classes.

What is ignored by this tool

• Extended ModuleDependencyProvider.
• Extended ModuleConfig.

Installation

composer require --dev spryker-sdk/composer-constrainer

This is a development only "require-dev" module. Please make sure you include it as such.

Add the console command SprykerSdk\Zed\ComposerConstrainer\Communication\Console\ComposerConstraintConsole to your Pyz\Zed\Console\ConsoleDependencyProvider::getConsoleCommands() stack.

Documentation

Spryker Documentation

Spryker OS is modular and follows SemVer. Every BC-breaking change of module API (https://docs.spryker.com/docs/scos/dev/architecture/module-api/module-api.html) is considered as a major release. But what happens to non-API? Spryker leverages the ability to change non-API functionality in minor and patch releases. This way Spryker provides new features for different business verticals.

What does it mean for my customized modules?

When you customized Spryker modules (changed module behavior on project level) even minor changes could potentially cause migration efforts. To avoid such cases and keep project updates safe and predictable a project should use ~ (tilde) composer constraint instead of ^ for modules with changed behavior. And to simplify the process Spryker provides a development command vendor/bin/console code:constraint:modules, which will suggest required changes in composer.json. It can also auto-adjust your composer.json.

Usage

Dry-run the command

vendor/bin/console code:constraint:modules -d

With this command no changes will be made to the composer.json. Use -v to see version details.

The return code of this command is either 0 (success) or 1 (error, some constraints need to be changed).

This is the recommended hook for your CI system.

Run the command

vendor/bin/console code:constraint:modules

This command will change the project's composer.json. Please dry-run the command before you apply any changes.