## Problem/Motivation The `ai` module ships a deprecated copy of Field Widget Actions at `ai/modules/field_widget_actions/`. Its `field_widget_actions.info.yml` is already marked: `lifecycle: deprecated lifecycle_link: https://www.drupal.org/node/3568339 ` This bundled copy has the **same machine name** (`field_widget_actions`) **and the same PHP namespace** (`Drupal\field_widget_actions\`) as the standalone contrib project https://www.drupal.org/project/field_widget_actions. When both are present in a codebase — which happens for any project that has `drupal/ai` as a (dev) dependency alongside the standalone module — the two modules collide. The most damaging symptom is during testing: the PHPUnit test-runner registers the `Drupal\field_widget_actions\` namespace for **both** directories, so `new \Drupal\field_widget_actions\Hook\FieldWidgetAction()` (or any direct class reference) can resolve to the **stale bundled copy** instead of the module under test. Which one wins depends on extension-discovery order, which differs between environments (e.g. a module placed under `modules/custom/` on drupal.org GitLab CI vs `modules/contrib/` locally). This caused real, hard-to-diagnose CI failures on the standalone `drupal/field_widget_actions` project: kernel tests passed locally but failed on drupal.org CI because the runner loaded the **old** bundled hook (which lacks newer logic). The standalone project currently has to work around it by deleting the bundled copy in its `.gitlab-ci.yml` before the tests run — a workaround that lives in the wrong repository. ## Steps to reproduce 1. In a project that requires `drupal/ai` (dev), also install the standalone `drupal/field_widget_actions`. 2. Note both modules share the machine name `field_widget_actions` and the namespace `Drupal\field_widget_actions\`. 3. Run PHPUnit/`run-tests.sh` for the standalone module. Depending on discovery order, `Drupal\field_widget_actions\*` classes may resolve to `ai/modules/field_widget_actions/...` rather than the standalone. ## Proposed resolution Finish the deprecation by removing the bundled copy and depending on the standalone project instead: 1. Add `"drupal/field_widget_actions": "^1.0"` to the **`require`** of the relevant package (most naturally `ai_automators`, since it is the consumer — see API note below). Use `require`, **not** `replace`: `replace` would declare that `ai` provides `field_widget_actions` and would _prevent_ the standalone from ever being installed, which is the opposite of the goal. 2. Delete `ai/modules/field_widget_actions/` entirely. 3. Add an update/release note: sites that enabled the bundled `field_widget_actions` module keep working seamlessly because the standalone has the identical machine name and namespace (the `core.extension` entry simply resolves to the standalone). No config or data migration is required; the only requirement is that the standalone package is now installed, which the new `require` handles automatically on `composer update`. ## Why this is safe (evidence) * **No info.yml coupling to update:** no `ai` sub-module declares `dependencies: field_widget_actions` in its `*.info.yml`, and the bundled module has no `composer.json`, no `.install`/`hook_update_N`, and no README. * **The standalone is a drop-in:** every symbol that `ai_automators` imports from the module is provided by the standalone with the same namespace — `Attribute\FieldWidgetAction`, `FieldWidgetActionBase`, and `Traits\ImageAltTextActionButtonTrait`. * **Verified empirically:** removing the bundled copy and running the full Field Widget Actions test suite (kernel + functional + functional-javascript, including the `ai_automators`-backed entity-reference autocomplete-tags test) passes against the standalone module. ## API / coupling note `ai_automators` ships \~30 `FieldWidgetAction` plugins (Boolean, Json, Text, ImageAltText, AutoCompleteTagsTaxonomy, …). All extend `Drupal\field_widget_actions\FieldWidgetActionBase` (via `AutomatorBaseAction`) and use `Drupal\field_widget_actions\Attribute\FieldWidgetAction` and `Drupal\field_widget_actions\Traits\ImageAltTextActionButtonTrait`. The runtime integration is gated by `\Drupal::moduleHandler()->moduleExists('field_widget_actions')` (see `ai_automators/src/Plugin/AiAutomatorProcess/FieldWidgetProcessing.php`), but the plugin **class definitions** still need the base class/attribute/trait to be present in the codebase. The bundled copy is what currently provides them, which is exactly why this can't be a bare directory deletion — it must be paired with the `require` on the standalone. ## Remaining tasks * \[ \] Add `drupal/field_widget_actions` to `require` (ai_automators, and/or ai root). * \[ \] Delete `ai/modules/field_widget_actions/`. * \[ \] Decide whether `ai_automators` should hard-depend on the module (`dependencies: field_widget_actions:field_widget_actions` in info.yml) or keep the current optional/`moduleExists` integration. (Lean: keep optional; the `require` only guarantees the code is present.) * \[ \] Add an upgrade/release note for sites currently using the bundled module. * \[ \] After release: remove the interim strip-step workaround from the standalone project's `.gitlab-ci.yml`. ## User interface changes None. ## Data model / configuration changes None. Machine name and namespace are unchanged, so existing `field_widget_actions`-related configuration and `core.extension` entries continue to resolve.