The manifest table wired nine formats and composer.json was not one, so a
PHP repo produced no module nodes and no dependency edges at all — only the
generic JSON extractor's top-level key variables, which reach neither
`require` nor `autoload`.
ParseComposerJSON and ParseComposerLock follow the package.json template:
require-dev is Indirect with the block tagged on Replace, versions stay
verbatim because composer.lock carries the resolved ones, and a malformed
manifest yields nothing rather than failing the index. Platform
requirements are skipped — `php`, `hhvm`, `ext-*`, `lib-*` and the
`composer-*` runtime pseudo-packages name no installable package, so a
module node for them could never be depended on by anything.
The manifest node is tagged "json", not "php": it shares its ID with the
JSON extractor's file node, and a php-tagged file would vouch for PHP
presence in a repo holding no PHP source. Module nodes do carry php via
ecosystemLanguage, which the per-repo language census ignores for
KindModule.
composer.json's autoload map is the only statement a PHP repo makes about
which namespaces are its own, so the PSR-4 and PSR-0 prefixes — from both
`autoload` and `autoload-dev`, and accepting composer's string-or-array
value — ride the manifest node. Attributing a VENDOR import to the package
that provides it is not attempted: composer.json says which packages are
required, not which namespace each one owns, and the vendor/pkg to
Vendor\Pkg correspondence is convention rather than rule (monolog/monolog
serves the Monolog namespace). Guessing it would mint wrong edges.
Verified on monolog: 19 composer modules (1 production, 18 dev) with the
autoload root `Monolog => src/Monolog, tests/Monolog`.
Andrey Kumanyaev
0b69295d24