Nils Adermann
Nils Adermann
@cweagans The problem is that the patch listed in some package is at https://some-maintainers-basement.com/foo/bar/123.patch - now as a business that relies on this patch getting applied when deploying, I don't...
I think I'd rather add it to this plugin in a transparent way, so that we don't have to force people to install another plugin on existing projects to make...
Sounds like this might be a compatibility problem with the latest OS X, @peritus?
@stof see https://github.com/composer/composer/pull/9619#discussion_r760237931 ?
If we build this into composer update we may need to consider adding this metadata to the information packagist.org provides by default, instead of contacing an additional endpoint.
@Seldaek There are actually additional features listed in this issue which are not yet implemented, so reopening.
I think it'd make a huge difference. As usual people will ignore warnings. Making Composer skip known-vulnerable versions by default is going to have a very positive impact. I don't...
I think even without the performance benefits this could still be a very worthwhile feature, so going to keep this open for now. Apart from projects you are very familiar...
I think adding a separate composer.json file for this which may exist in different directories based on the project is really a step backward from standardized composer.json at the root...
To focus on your use case first, what problems do you see with using "--prefer-source" when installing the framework's deps, and then working on your plugin/module/bundle inside the git clone...