Add tests

#3578012: Fix phpstan report is a blocker as any Kernel test fails without a compatibility fix in the Validator implementation.

Ok, it is unblocked now, let me review the state of the tests locally.

Beside adding test coverage, I addressed the following compatibility issues:

- Convert @FieldType, @FieldFormatter, @FieldWidget annotations to PHP
attributes (available since Drupal 10.2)
- Add native return types to all overridden methods (array, bool, void)
- Replace global t() with new TranslatableMarkup() in static context
- Rewrite SshKeyConstraint constructor with explicit named parameters,
removing deprecated $options array fallback
- Remove deprecated getDefaultOption()/getRequiredOptions() (Symfony 7.4 no longer need it)
- Fix SshKeyConstraintValidator::validate() signature to match
ConstraintValidatorInterface (mixed $value, Constraint $constraint): void
- Add null safety for explode() in Utils.php and property access in
TextareaWidget.php

I applied the patch locally and reviewed the changes.

The addition of test cases looks appropriate and improves coverage for the module. The changes across the codebase seem consistent with supporting the new tests.

I did not notice any unrelated modifications, and the implementation appears well-scoped.

Looks good to me.

RunTestsInSeparateProcesses is an optional annotation in D10 and below. In 11.3.x and up, it's now an attribute, and apparently, required.

https://www.drupal.org/node/3548485

Since the attribute doesn't exist in D10, phpstan is complaining about it. I don't know if you actually *need* to define it in D11, I think it'll just be required in D12. In theory, it does no harm in D10, but you probalby want to add it to your phpstan config to ignore it in D10.

Meanwhile, I'm proposing we move all of these OPT_IN jobs to require a manual trigger, so we don't waste nearly as much CO2 and DA $$ running excessive pipeline jobs on every push to every MR. See https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/468 IMHO, maintainers should trigger them manually when an MR is getting close to being merged, but they're mostly a waste of resources in the early phases of most issues.

Until that happens, you could set it up manually. Or, you could consider not adding all these OPT_IN* things to your default config that runs "all the time".

Especially the upgrade status job. 😬 You really only need to run that a few times once every 2 years when you're porting to a new major version of core. 😅 I'd strongly recommend *not* putting that in the default .gitlab-ci.yml file, and just trigger a manual pipeline if you really want to see the results (or add it to the .gitlab-ci.yml in an issue fork where you're actively working on porting to the next version of core).

Cheers,
-Derek

I disabled the rest of the checks for now, it's definitely worth making them trigger manually to check eventual compatibility declared in the info file.

#10: +1 to PHPUnit\Framework\Attributes\RunTestsInSeparateProcesses it is optional. That's why the validation result for the previous major did not fail the validation stage entirely.

We can enable back compatibility checks while working on other issues.

Restoring the status.

I leave them there to have a toggle to check as needed. This will save a couple of minutes when reviewing the MR. Just make a commit with the target check commented out and see the result, then comment it back in to prevent it from triggering the main branch check after the MR is merged. Sometimes, searching through the documentation took longer than just uncommenting the line. See #3572380 how that interaction with manual triggering can be improved in the future.

Rebased and addressed #12

Cool.

@colan: would you be willing to update the contribution record to at least credit @voleger for all his work here, and perhaps also me for the time I took to explain things?

For the future, it’s sorta nice if you do that before you push the commit, so you can add the recommended “By: xyz” trailers. See the linked contribution record for details.

Thanks!
-Derek

P.s. I would not credit @shivansh_0909 since they seem to be using an LLM to post slop / noise in various drive-by issues.

It’s a separate site, so you have to log in periodically. It’s SSO with d.o, so you just click the login link and it should do the deed and redirect you back.

It’ll be more smooth once the DA finishes migrating all the parts of the D7 d.o to the new world.

Meanwhile, yeah, the UX sucks, and even the UI is pretty bad that it doesn’t make it more obvious you’re not logged in. 😢

All you get, if you read the fine print, is:

If you are credited below, log in to make any changes to your attribution.

That needs to be a giant yellow warning at the top of the page it something. 😂