scan_composer

tech.tresbien/drupal-code-query · Verify this server

Which of a site's drupal/* packages need a new release for a target core, and which have none? Send composer.lock (and composer.json) once instead of one query per package; the answer is the release scan for every package plus extra.patches as check_patches items. Constraints are read by composer's own semver library. - composer_lock: the file, or the slim form {"packages":[{"name","version"}]} for drupal/* only. composer_json adds constraints and extra.patches. target_core: 11.4 or 11.4.5; empty scans against the installed core (target_is_installed), i.e. what can be updated without a core upgrade. - rows, ranked problems first: no_release (no published release supports the target; latest_any and dev_branch say what exists), update (a compatible release the site does not have: latest, latest_core), unknown (not a drupal.org project in the bundle; the note says where its releases are), current (installed_supports and nothing newer needed; such a row carries package, installed and installed_supports only). counts covers every package even when rows are cut. - candidates on every row that is not current: the newest three releases with version, core constraint, date and supports_target. That is what choosing a version needs; project_profile adds installs and branches, not more releases. - patches: one item per extra.patches entry with the installed version filled in; pass them to check_patches after composer update (local paths need the file text). - patches:true answers with plan instead: every patch judged against the release its package would install for target_core, so the join needs no second call. plan.counts is the verdict tally, plan.package_counts the scan tallies, plan.no_release the packages that block the target, plan.patches one row per patch needing a decision (needs-reroll, unknown, shipped), and plan.still_needed the number that apply and are still required. The scan rows themselves are not in a plan; call again without patches for them. A patch whose package has no release for the target is unknown with the reason in note; a row's project for reroll_patch is its package without the drupal/ prefix. - A plan never carries a re-rolled diff: plan.next_step names reroll_patch, one call per patch, when any patch no longer applies. - bundle_date is when the release data was published; a release after it is invisible here, so confirm a no_release with composer show or drupal.org before acting.