Use PHIVE to manage PHPUnit

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.

[tfrommen]

This PR introduces PHIVE to manage PHPUnit. For more information on PHIVE, please refer to the officialwebsite.

Instead of including PHPUnit as a Composer (dev) dependency, we would run phive install, and have PHPUnit (symlinked) available at tools/phpunit inside our project root.

Not having PHPUnit as a Composer dependency would mean that, in addition to PHPUnit itself, also all these packages are no longer installed:

Package operations: 0 installs, 0 updates, 26 removals
- Removing webmozart/assert (1.9.1)
- Removing symfony/yaml (v4.4.19)
- Removing symfony/polyfill-ctype (v1.22.0)
- Removing sebastian/version (2.0.1)
- Removing sebastian/resource-operations (1.0.0)
- Removing sebastian/recursion-context (2.0.0)
- Removing sebastian/object-enumerator (2.0.1)
- Removing sebastian/global-state (1.1.1)
- Removing sebastian/exporter (2.0.0)
- Removing sebastian/environment (2.0.0)
- Removing sebastian/diff (1.4.3)
- Removing sebastian/comparator (1.2.4)
- Removing sebastian/code-unit-reverse-lookup (1.0.2)
- Removing phpunit/phpunit-mock-objects (3.4.4)
- Removing phpunit/phpunit (5.7.27)
- Removing phpunit/php-token-stream (2.0.2)
- Removing phpunit/php-timer (1.0.9)
- Removing phpunit/php-text-template (1.2.1)
- Removing phpunit/php-file-iterator (1.4.5)
- Removing phpunit/php-code-coverage (4.0.8)
- Removing phpspec/prophecy (v1.10.3)
- Removing phpdocumentor/type-resolver (1.4.0)
- Removing phpdocumentor/reflection-docblock (5.2.2)
- Removing phpdocumentor/reflection-common (2.2.0)
- Removing myclabs/deep-copy (1.10.2)
- Removing doctrine/instantiator (1.4.0)

This means a 11M smaller vendor folder (14M vs. 25M).

I'll leave this PR here for discussion. 🤓

[missjwo]

It looks super cool, but I am wondering if the 11M vendor folder is worth the extra tool? My head says yes, but I want to make sure it is. Is one of the upside with composer is that it's all together. 🤔

[tfrommen]

I am wondering if the 11M vendor folder is worth the extra tool?

The reduced size is more a side effect, to be honest. It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

For example, coding standards would live in composer.json as they are project-specific. You define what makes the coding standards and rules to use for a given project. But the tool to perform these checks doesn't have to live with the project. All you need is a manifest that dictates what version to use.

This separation prevents running into issues that are no real issues, such as dependency conflicts.

[missjwo]

It's about clear separation between production and development dependencies of the software being developed and the software you need as a developer.

My bad, i totally missed that point in your post 🙈

[ntwb]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. npm install
2. composer install

Having to manage another would add:

3. phive install

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

I guess my question is, is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

[tfrommen]

Adding another tool to install tools doesn't excite me to be honest, we have 2 right now:

1. `npm install`
2. `composer install`

Having to manage another would add:

1. `phive install`

Well yes. That's because they are all for different things.

And to be fair, you could easily use a build or install script such bin/install.sh or whatever you fancy, so it's just a single command to get it all set up. I'm fine with the separation, and actually welcome it. Managing your software dependencies and managing your tools are two different things after all.

I also like that dependabot can automate these dependency updates e.g here, it appears Phive is not supported by dependapot.

Yeah, automatically checking dependencies for updates or issues would be nice.

is reducing the /vendor folder size by ~11M instead of automated dependency updates worth it?

It's not primarily about the reduced size, as I mentioned in my last comment. Quoting from the post I wrote:

...all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.

Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.

Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.