This issue is related to #340 somewhat, except it proposes more drastic measures. This issue also applies to more than just phpstan/extension-installer, but any dev -ish dependency, including spaze/phpstan-disallowed-calls.
Presently, when require -ing govcms/scaffold tooling, PHPStan and other dev dependencies are brought in and are forced to be present even in production. This is not ideal, as dev tooling is by design not evaluated for security issues. By their nature, they will contain security issues and performance implications, and generally increase the bytesize of a deployed application.
phpstan should never be present on production, any development or testing tool should not be present on production. Packages like phpunit even disclaim responsibility when installed on a production web server.
With Composer, its not possible to move these dependencies to govcms/scaffold-tooling and have them be installed by other projects only in dev. This is because Composer -dev dependencies not recursive by-design. They are for the root project only.
Proposed solution
Just like how Drupal core itself has a drupal/core-dev dependency, it may be necessary to to introduce a govcms/scaffold-tooling-dev.
The workflow for dealing with this circumstance is to introduce a new -dev package containing development related dependencies, and have downstream projects depend on that in their require-dev section.
You could consider having the -dev package in this project, mixing a CI workflow with splits. Or a completely unique Github project.
This issue is related to #340 somewhat, except it proposes more drastic measures. This issue also applies to more than just phpstan/extension-installer, but any
dev-ish dependency, includingspaze/phpstan-disallowed-calls.Presently, when
require-ing govcms/scaffold tooling, PHPStan and other dev dependencies are brought in and are forced to be present even in production. This is not ideal, as dev tooling is by design not evaluated for security issues. By their nature, they will contain security issues and performance implications, and generally increase the bytesize of a deployed application.phpstan should never be present on production, any development or testing tool should not be present on production. Packages like phpunit even disclaim responsibility when installed on a production web server.
With Composer, its not possible to move these dependencies to govcms/scaffold-tooling and have them be installed by other projects only in dev. This is because Composer -dev dependencies not recursive by-design. They are for the root project only.
Proposed solution
Just like how Drupal core itself has a
drupal/core-devdependency, it may be necessary to to introduce agovcms/scaffold-tooling-dev.The workflow for dealing with this circumstance is to introduce a new -dev package containing development related dependencies, and have downstream projects depend on that in their
require-devsection.You could consider having the -dev package in this project, mixing a CI workflow with splits. Or a completely unique Github project.