altis/dev-tools as a dependency causes unnecessary non-dev dependencies

[johnbillion]

If you follow the basic Getting Started instructions for an Altis project you end up with a bunch of testing libraries in your Composer dependency graph when installing the site for production use with composer install --non-dev.

This includes phpunit/phpunit, wp-phpunit/wp-phpunit, and others.

The reason is that this altis/altis meta package has altis/dev-tools as a non-dev dependency, which in turn has a non-dev dependency on phpunit/phpunit and wp-phpunit/wp-phpunit.

I think the problem is that altis/dev-tools should be a dev dependency rather than a dependency.

Thoughts?

[johnbillion]

Having given it further thought, I think the problem is that the altis/dev-tools package is a combination of stuff that you want deployed (debugging plugins) and stuff that you don't (PHPUnit) but they're packaged together. Maybe altis/dev-tools needs to be split into two packages?

[roborourke]

@johnbillion yeah that's a difficult one because dependencies can't install their dev dependencies when you run the install from your root project. It's not ideal to have phpunit installed in the production environment I agree.

There are a few options we could consider here:

• Add handling to the core installer to install a module's dev dependencies when not carrying out a no-dev install
• Similar to the above but have modules define which dependencies should be ignored in a production install
• Allow for a second step in module installation that installs additional dependencies if no-dev isn't specified using composer install <package>, ... from the root so the composer.json isn't updated

I think the first one might be the best option, or along those lines.

Can you elaborate more on how an additional package would solve the issue? Another meta package of dev dependencies like this?

{
   "require": {
      "altis/altis": "^3.0.0"
   },
   "require-dev": {
     "altis/dev": "^3.0.0"
   }
}

I'm more in favour of whatever solution keeps things easier to install.

[rmccue]

Apart from PHPUnit, are there any others?

[roborourke]

Nope not right now

[roborourke]

Thinking about this just now and I wonder if we can just get the phpunit command to install the necessary packages when it's run instead. Sort of JIT install.

[johnbillion]

My preference would be to split altis-dev-tools into two packages, one for the dependencies used on production (eg plugins) and one used for developer tooling (eg phpunit). They serve two different purposes really.

Then you could do as you suggest Rob and use the former in require and the latter in require-dev, either directly or themselves as dependencies of something like altis/altis and altis/altis-dev.

[roborourke]

Yeah that'd be simpler really. I guess an altis/dev package could then have local server and local chassis as dependencies... Or maybe call it altis/local 🤔

Seems like the cleanest solution. Thanks for your input @johnbillion

[roborourke]

Gonna park this for a bit and write up an RFC for the new module.

[johnbillion]

We noticed this effect again on SC today, there are almost 100 unnecessary non-dev dependencies being pulled in as a result of altis/dev-tools dependencies which should be dev dependencies. They come from Codeception, wp-browser, phpunit, and the phpunit tools.

Can this package be split up please?

[johnbillion]

Here's the list, if you're interested

antecedent/patchwork
behat/gherkin
bordoni/phpass
codeception/codeception
codeception/lib-asserts
codeception/lib-innerbrowser
codeception/module-asserts
codeception/module-cli
codeception/module-db
codeception/module-filesystem
codeception/module-phpbrowser
codeception/module-webdriver
codeception/phpunit-wrapper
codeception/stub
codeception/util-universalframework
dg/mysql-dump
doctrine/inflector
doctrine/instantiator
guzzlehttp/guzzle
guzzlehttp/promises
guzzlehttp/psr7
illuminate/collections
illuminate/contracts
illuminate/macroable
illuminate/support
lucatume/wp-browser
mikehaertl/php-shellcommand
mikemclin/laravel-wp-password
mustache/mustache
myclabs/deep-copy
nesbot/carbon
nikic/php-parser
phar-io/manifest
phar-io/version
php-webdriver/webdriver
phpunit/php-code-coverage
phpunit/php-file-iterator
phpunit/php-invoker
phpunit/php-text-template
phpunit/php-timer
phpunit/phpunit
psr/container
psr/event-dispatcher
psr/http-client
psr/http-factory
psr/http-message
psr/simple-cache
ralouphie/getallheaders
rmccue/requests
sebastian/cli-parser
sebastian/code-unit
sebastian/code-unit-reverse-lookup
sebastian/comparator
sebastian/complexity
sebastian/diff
sebastian/environment
sebastian/exporter
sebastian/global-state
sebastian/lines-of-code
sebastian/object-enumerator
sebastian/object-reflector
sebastian/recursion-context
sebastian/resource-operations
sebastian/type
sebastian/version
symfony/browser-kit
symfony/console
symfony/css-selector
symfony/deprecation-contracts
symfony/dom-crawler
symfony/event-dispatcher
symfony/event-dispatcher-contracts
symfony/finder
symfony/polyfill-ctype
symfony/polyfill-intl-grapheme
symfony/polyfill-intl-normalizer
symfony/polyfill-mbstring
symfony/polyfill-php73
symfony/polyfill-php80
symfony/process
symfony/service-contracts
symfony/string
symfony/translation
symfony/translation-contracts
symfony/yaml
theseer/tokenizer
voku/portable-ascii
vria/nodiacritic
wp-cli/mustangostang-spyc
wp-cli/php-cli-tools
wp-cli/wp-cli
wp-phpunit/wp-phpunit
yoast/phpunit-polyfills
zordius/lightncandy

[roborourke]

Might be able to do something similar to the trick with installing plugin packages to vendor, if Altis modules can indicate overrides for things to install as dev dependencies only.

Only a subset of that list but I think Guzzle will be required by the AWS SDK anyway.

[roborourke]

@johnbillion is this causing specific problems with the container build size limitations?

[johnbillion]

is this causing specific problems with the container build size limitations?

Nope, just something we noticed while doing dependency updates today

[rmccue]

I'm not sure on what the issue is here ultimately, aside from having unused code?

[johnbillion]

Yes that's the issue, we have a greatly inflated dependency tree which means time gets spent periodically updating dependencies that aren't used.