Remove unused psr/log dependency

[jhm-ciberman]

Description

Fixes #38

Motivation and context

Fixes #38

How has this been tested?

If it passes CI, it works™

Screenshots (if appropriate)

Types of changes

What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

• I have read the CONTRIBUTING document.
• My pull request addresses exactly one patch/feature.
• I have created a branch for this patch/feature.
• Each individual commit in the pull request is meaningful.
• I have added tests to cover my changes.
• If my change requires a change to the documentation, I have updated it accordingly.

If you're unsure about any of these, don't hesitate to ask. We're here to help!

[jhm-ciberman]

Another alternative is to allow both version v2 and v3 in the package.json. But since the dep is not used, I don't see why.

[jhm-ciberman]

@JaZo It would be useful if you can merge and release a new version on packagist. I would love to use this package in our project since it looks very complete and integrating mautic from scratch seems like a pain haha.

[JaZo]

This dependency was added because the underlying package (mautic/api-library) is incompatible with version 3, but allowed installation (see mautic/api-library#273 and mautic/api-library#286). By adding the v2 constraint, we could prevent installation of v3 and make sure everything works. A fix has been merged in the underlying package, but it will only be released in the next major, because it's considered breaking, and that version is still in beta.

TL;DR: We can't remove the dependency as it will break the code.

[JaZo]

@jhm-ciberman, you might be able to downgrade psr/log and still be able to install this package. Almost every package is compatible with v1-v3. Alternative is to use your own branch and add a patch (mautic-api-library-psr-log-v3.patch) for mautic/api-library with something like cweagans/composer-patches to fix the issue.

[jhm-ciberman]

Oh, that seems way more problematic that I imagined. I understand, the problem is mautic/api-library that they haven't released a new stable version since 2022.

you might be able to downgrade psr/log and still be able to install this package. Almost every package is compatible with v1-v3.

About downgrading to v2. It seems we are using google/auth in our codebase which requires psr/log v3. So I can't easily downgrade to v2.

$ composer why-not psr/log v2
google/auth v1.45.0 requires psr/log (^3.0)
Not finding what you were looking for? Try calling `composer update "psr/log:v2" --dry-run` to get another view on the problem.

Alternative is to use your own branch and add a patch (mautic-api-library-psr-log-v3.patch) for mautic/api-library with something like cweagans/composer-patches to fix the issue.

About that approach of patching forking + patching, it sounds possible but I want to think of other simpler solutions first.

Could this project source code compatible with mautic/api-library v4-beta? Even if it's marked as beta maybe I can fork swisnl/laravel-mautic and change the mautic/api-library dependency to v4.0.0-beta. That would fix the psr/log issue. I tested that locally in a separate branch in my fork and it seems to work.

I can create a PR and then maybe you could publish that as swisnl/[email protected]. (Or maybe 0.4.0-beta if you want to remain in the v0 release cycle). We can use a beta pre-release version to indicate that the package itself depends on other beta package and thus composer should not use that version by default. I think that could be a good workaround to benefit from the changes made to mautic/api-library. What do you think?

[jhm-ciberman]

@JaZo I added a PR with the solution described above #40

I think this is a good balance while we wait for another stable release from mautic/api-library. Feel free to share your thoughts if you disagree.