Problem/Motivation

Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead.

Proposed resolution

It is very easy to switch packages as they are almost identical

CommentFileSizeAuthor
#2 3366450-switch-from-webmozartpath-util-2.patch841 bytesholo96

Issue fork drush_language-3366450

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

DavorHorvacki created an issue. See original summary.

holo96’s picture

holo96 commented
StatusFileSize
new 3366450-switch-from-webmozartpath-util-2.patch841 bytes

Think this will do it.

holo96’s picture

holo96 commented
Status: Active » Needs review
rcodina’s picture

rcodina
Primary language Catalan
Location Barcelona
commented

Patch on #2 works for me.

tido’s picture

tido
Location Montpellier
commented

Do you have any idea when this modification will be validated and packaged in a new version of the module?

For people who have automated tests in a CI, for example with composer audit, the webmozart//path-util package appears as abandoned and so CIs often fail.

rcodina’s picture

rcodina
Primary language Catalan
Location Barcelona
commented
Status: Needs review » Reviewed & tested by the community

Two positive reviews.

marcoliver’s picture

marcoliver
he/him
Primary language German
Location Neuss, NRW, Germany
commented

Any chance of this and https://www.drupal.org/i/3485647 getting merged some time soon?

Because yes, drush language:* is mostly a replacement for this module, but there is some convenience stuff in here that would be cool to keep!

hitchshock made their first commit to this issue’s fork.

hitchshock opened merge request !2

jan kellermann’s picture

jan kellermann commented

RTBC and please merge an release version.

watkinsj’s picture

watkinsj commented

When applying the patch into the composer.json will it still show the issue on composer audit?

I set the patch in composer.json and ran composer install, but the audit still shows the error.

marcoliver’s picture

marcoliver
he/him
Primary language German
Location Neuss, NRW, Germany
commented

@watkinsj Unable to verify this right now, but AFAIK composer audit scans your composer.lock file for packages with known vulnerabilities and packages that depend on ones with known vulnerabilities.

Maybe take a look at your drush_language entry in the lock file and its dependencies. Or maybe audit knows that drush_language has inherited an issues from its dependency?

prudloff’s picture

prudloff commented

Patching composer.json does nothing because Composer reads the dependencies from the remote repository (when adding or updating a dependency) or from your composer.lock file (on subsequent installs), not from the patched composer.json file.