You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Composer installers allows custom paths for package names. I think this is very useful, especially if you have not control of the package to implement and you do not want to rely on the composer type of the package. Therefore I'd propose to switch to the same syntax as Composer Installers.
Not really, as it lacks the replacement patterns. Sure that would not be necessary, as we have a specific name. But with the Composer Installers syntax you can provide multiple packages for a single path pattern. This would be a better experience from my perspective.
In addition it feels some kind of odd to me, to use separate installers for quite the same task. I'd very much would like to see one go-to-solution for custom paths, instead of splitting up the core code to separate installers in separate versions and separate reasons of why thinks do not work.
So I thought your installer would be a great starting point for that. If you would not like that, I'd try to fork composer/installers for that custom purpose :)
Composer installers allows custom paths for package names. I think this is very useful, especially if you have not control of the package to implement and you do not want to rely on the composer type of the package. Therefore I'd propose to switch to the same syntax as Composer Installers.
Is this something you are interested in? As so, I'd try to create a PR for that.
The text was updated successfully, but these errors were encountered: