Skip to content

Conversation

@jrfnl
Copy link
Member

@jrfnl jrfnl commented Apr 2, 2025

Proposed Changes

Modernize: use InstalledVersions::isInstalled()

The Composer runtime-api 2.0 introduced the \Composer\InstalledVersions::isInstalled() method.

This commit starts using that method.

Implementation choices:
While it would be possible to also handle the version checking via Composer\InstalledVersions::satisfies(new VersionParser, self::PACKAGE_NAME, (string) $versionConstraint), this would require adding a new dependency "composer/semver": "^3.0".
For now, I've chosen not to add the dependency and to leave the pre-existing code for handling version constraints.

Ref: https://getcomposer.org/doc/07-runtime.md#installed-versions

Modernize: use InstalledVersions::getInstallPath()

The Composer runtime-api 2.1 introduced the \Composer\InstalledVersions::getInstallPath() method.

This commit starts using that method.

Ref: https://getcomposer.org/doc/07-runtime.md#knowing-the-path-in-which-a-package-is-installed

Related Issues

Follow up on #230

👉🏻 Note: I have another modernization lined up, but am running into a bug in Composer. Holding that one back for now.

@jrfnl jrfnl added this to the 1.1.0 milestone Apr 2, 2025
jrfnl added 2 commits April 2, 2025 14:54
The Composer runtime-api 2.0 introduced the `\Composer\InstalledVersions::isInstalled()` method.

This commit starts using that method.

Implementation choices:
While it would be possible to also handle the version checking via `Composer\InstalledVersions::satisfies(new VersionParser, self::PACKAGE_NAME, (string) $versionConstraint)`, this would require adding a new dependency `"composer/semver": "^3.0"`.
For now, I've chosen not to add the dependency and to leave the pre-existing code for handling version constraints.

Ref: https://getcomposer.org/doc/07-runtime.md#installed-versions
The Composer runtime-api 2.1 introduced the `\Composer\InstalledVersions::getInstallPath()` method.

This commit starts using that method.

Ref: https://getcomposer.org/doc/07-runtime.md#knowing-the-path-in-which-a-package-is-installed
@jrfnl jrfnl force-pushed the feature/modernize-after-composer-lt-2.2-drop branch from 012a35b to 7b7cbbd Compare April 2, 2025 12:54
@jrfnl
Copy link
Member Author

jrfnl commented Apr 2, 2025

Hang on - this PR still contained a commit from another PR, so I've rebased this to drop that extraneous commit (without other changes)

Copy link
Member

@Potherca Potherca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just to be clear: We're breaking backward compatibility on purpose, right?

I.e, we're not checking whether Composer\InstalledVersions exist, as we are bumping the required version of composer to versions that are quaranteed to contain Composer\InstalledVersions.

(Just double-checking, as I've been out of touch with this project for a while).

@jrfnl
Copy link
Member Author

jrfnl commented Apr 14, 2025

Looks good. Just to be clear: We're breaking backward compatibility on purpose, right?

I.e, we're not checking whether Composer\InstalledVersions exist, as we are bumping the required version of composer to versions that are quaranteed to contain Composer\InstalledVersions.

Exactly, the version bump for the Composer API was already done in PR #230 and as this tool is a Composer plugin and therefore only needs to take installation via Composer into account, we don't need to check with function_exists() or anything.
IF the version of this package is installed containing this change, this means by definition that the user WILL have the right Composer version installed. (Otherwise, they wouldn't get the new version of this package, as Composer would have installed the last version from before the drop of support for Composer < 2.2).

@jrfnl jrfnl merged commit 648b84f into main May 2, 2025
74 checks passed
@jrfnl jrfnl deleted the feature/modernize-after-composer-lt-2.2-drop branch May 2, 2025 14:18
jrfnl added a commit that referenced this pull request Jun 25, 2025
…#245)

Revert one of the modernizations previously made in #234 due to it causing issues in Drupal installations.

I'm very curious why the reported issue only appears to happen with a Drupal setup (and I cannot reproduce it, nor do our tests fail). All the same, this should fix it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

4 participants