Define requirements in composer.json

[fredden]

Following some feedback on #3752 about an extension that I'd forgotten to add to composer.json, I have set up maglnet/composer-require-checker to automatically detect such errors in future. While doing so, I noticed that the following extensions are already required, but were not listed in composer.json:

• ctype -

  PHP_CodeSniffer/src/Tokenizers/JS.php

  Line 859 in add95a7

  if (ctype_digit($newContent) === true) {

• dom -

  PHP_CodeSniffer/src/Generators/Generator.php

  Line 93 in add95a7

  $doc = new \DOMDocument();

• iconv -

  PHP_CodeSniffer/src/Reports/Xml.php

  Line 57 in add95a7

  $error['message'] = iconv($phpcsFile->config->encoding, 'utf-8', $error['message']);

• json -

  PHP_CodeSniffer/src/Util/Cache.php

  Line 291 in add95a7

  file_put_contents(self::$path, json_encode(self::$cache));

• libxml -

  PHP_CodeSniffer/src/Ruleset.php

  Line 324 in add95a7

  libxml_use_internal_errors(true);

Additionally, there was no autoload section in composer.json, which I have now added.

I had to create configuration for the checker tool to avoid it complaining about a large number of (global) constants that are defined here.

[jrfnl]

@fredden Thanks for the PR. I can't say anything about whether it will be accepted or not, but can give you some feedback in general terms, but in the end, it's @gsherwood's decision.

• Most of the extensions you now listed in require are only needed for specific features, not for the application in general.
  As a matter of course, extensions which ship with PHP and can not be disabled do not need to be listed.
  The five extensions you've now added all ship with PHP and are all enabled by default (though most can be disabled).
  In most cases, the uses of those extensions will be conditional on the extension being available, which means the extension is not actually required (though could be added to suggest with a hint as to which functionality requires the extension).
  It could be that in one or two cases, the "conditional use" has fallen through the cracks, in which case, that should be fixed (instead).
• The autoload sections are redundant as PHPCS handles this in the application bootstrap.
  Additionally, a PSR4 autoload section for the src directory can actually break the PHPCS translation between classes and sniff names, which is needed for the correct handling of (custom) rulesets.
  Furthermore, PHPCS also supports PHIVE, PEAR and git clone installs, so relying on Composer for the autoloading would be wrong and unstable.
• In my experience, the general tendency for PHPCS has been to have a minimal set of dependencies, even dev dependencies, so not sure adding a new tool will be welcome.

Sorry to be a party-pooper.

[fredden]

It could be that in one or two cases, the "conditional use" has fallen through the cracks, in which case, that should be fixed (instead).

Would it be helpful for me to open pull requests for each of the identified extensions, and add a "conditional use" check around these? We could then move these extensions from the require section to suggest.