Hi. I'm developing a modular application on Composer and have a question regarding dependency inclusions during development.
Currently I have the packages pulled from a VCS.
I have a core module which requires all other modules.
When developing the different modules, I would like to pull in the core module as it implements the user logic.
Though the problem is that when I require-dev the core module, then it tries to automatically install it's dependencies for the modules as well, causing a recursion: e.g
help-module > core > help-module...
Does Composer offer any possibilities to pull in a dev dependency without installing the sub-dependencies?
I took laravel/framework as a basis for mine. which yeah basically is the same structure that Symfony follows.
I do see that laravel makes use of the
replace keyword for replacing individual subpackages, but based on the docs I'm not 100% sure if this is a necessary thing for me as well.
Though yes a difference is that laravel supplies a separate laravel/app package which requires the laravel/framework (core) package.
So maybe I will get away by using
"type": "wordpress-plugin"but I need it to install into the vendor like a normal
"type": "library"is there anything i can do to overwrite it locally?
classmapsarray in the composer.json, but when i run the same script via the command line, it doesnt, i've put an exist in the autoloader_classmap.php and it never even hits it... any ideas?
dev-main-dev. When I
composer install, Composer installs the dependency at the version specified in
composer.lock(per its hash). So far so good. But when I
composer update vendor/library, Composer says
Nothing to install or update, even though there are many more commits that were made subsequent to the one specified in the lock-file.
git pull "origin" main-devmanually, all of those commits flow-in. Ultimately, my question is, why does
composer update vendor/librarynot bring in these same commits?
composer.jsonthen all packages...
composer update. You should be in the clear for
composer install, given the scenario you described.
composer installwill work in that environment,
composer updatemay not.
composer updatein production, though; he should be doing it elsewhere and then committing the
composer.lockfile once he's vetted it, and only ever running
composer installin production.
$ composer why-not slevomat/coding-standard [InvalidArgumentException] Could not find package "slevomat/coding-standard" in your project