Fix ESLint, phpcs, phpstan, cspell coding standards

Hi @ismaelromero,

I have checked the pipeline and re-ran the phpcs job. Confirmed no errors remaining and the job suceeded.

Will now move this to RTBC

Thanks,
Jake

The function doc comments need to be updated to match the changes.

PHPUnit failed in the pipeline. Is this the cause?

It passes on Drupal 11.0 but fails on 11.1 and 10.4. I think there was a change in those two that must be breaking it. I suspect it would also work on 10.3 if it was tested there. This looks like the issue addressed by #3491233: Fix Drupal 10.4 RC1 error with field_ui.js.

Thanks for working on this, just tagging with PHP 8.4, to easier follow along.

Works great on the 4.x branch! No deprecation warnings, and Field Group still works.

(People who contributed partial fixes to issues closed as duplicates who should get credit when this is fixed include prem suthar, deepali sardana, MrDaleSmith, and nickdickinsonwilde. And solideogloria who is already over here!)

The diff of issue fork can't be applied to the 3.6 version
The issue Fork 8..x-3 seems to be different of the main issue fork ? what should I apply.
Also got this depreciated but seems not to be resolved by the issue
PHP 8.4 got this depreciated :
Deprecated function : field_group_form_process(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead dans include_once() (/var/www/app/web/core/lib/Drupal/Core/Extension/Extension.php ligne 153)

Deprecated function : field_group_field_group_form_process_build_alter(): Implicitly marking parameter $form_state as nullable is deprecated, the explicit nullable type must be used instead dans include_once() (/var/www/app/web/core/lib/Drupal/Core/Extension/Extension.php ligne 153)

Message Deprecated function : field_group_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead dans include_once() (/var/www/app/web/core/lib/Drupal/Core/Extension/Extension.php ligne 153)

Message Deprecated function : field_group_field_layout_fields_nest(): Implicitly marking parameter $vars as nullable is deprecated, the explicit nullable type must be used instead dans include_once() (/var/www/app/web/core/lib/Drupal/Core/Extension/Extension.php ligne 153)

Message Deprecated function : field_group_group_save(): Implicitly marking parameter $display as nullable is deprecated, the explicit nullable type must be used instead dans include_once() (/var/www/app/web/core/lib/Drupal/Core/Extension/Extension.php ligne 153)

This issue is for fixing coding standards in the 4.x branch.

The "Implicitly marking parameter as nullable is deprecated" message has already been fixed in 4.x. The fix for it in 8.x-3.x is discussed in #3504453: Fix PHP 8.4.x deprecation and other warnings (PHPStan).

LGTM! The PHPUnit failure seems to be related to an ajax tests, which seems to fail randomly. As the test succeeded, right before I added a comment, everything will be fine.
We can tackle the random phpunit failures in a follow-up issue (They also succeed locally).

Reopened to finally also fix eslint in 3490746-fix-eslint

There are still issues raised by eslint.

Would be great to finally get this one resolved and pipeline green! :) Anyone?

Sure I can have a quick look and see what I can easily sort

@scott_euser sorry I was also working on this locally, have you already started? Just so that we don't both do the same thing for no reason here. If you're already on it right now then go ahead.

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

Well that opens up another can of worms. PHPStan is not keen about the deprecated DrupalSqlBase. It's really not up to me to decide whether to throw out the migrate classes or rework them differently, so any maintainer feedback would be greatly appreciated so that we may continue here.

@lrwebks for these two cases I'd suggest something like:

/**
 * @phpstan-ignore-next-line DrupalSqlBase is removed in Drupal 12 and has no replacement.
 */
class ...

As we don't have D12 support yet and will want to keep these migrations for 4.x-dev.

Okay go for it, will stop what I was doing, didn't get very far yet anyways

Alright @scott_euser, thank you for the effort nonetheless!

I don't even know what to make of some ESLint fixes that it wants me to do. I don't think that we need function docs for Drupal.once for example. Could anyone take a look at what is the best to do here?

Nice other fixes @lrwebks! Maybe @scott_euser can take over now for eslint? We're very close to the finish line! :)

Thanks, @scott_euser for fixing ESLint!

Feedback was addressed now, is this good to go now @anybody or anything else you need first?

Thank you all VERY much! Let's merge this :)

We introduced a minor regression here: "this.$regionSelect.val(region);" was replaced with "this.$regionSelect.get(0).value". They don't behave equally "get(0)" could return a nullish value, leading to .value throwing an error.

I'll fix it as part of #3613421: Moving fieldgroup under other fieldgroup from disabled, puts the child fieldgroup in disabled (even though it is unrelated).

Reverted them in https://git.drupalcode.org/project/field_group/-/merge_requests/141/diff.... I'll talk with @anybody internally, it would be cleaner to merge the changes seperately.

Not quite sure, why we even changed these parts. They shouldn't be concerned by ESLint and are not really cleaner, as both use jquery.

Ok, just applied the fixes through https://git.drupalcode.org/project/field_group/-/commit/6ef9c5c6073b3fc8....

Ok, it seems that core now uses the "eslint-plugin-no-jquery" so the eslint job still fails, as this module uses jquery quite a bit. I'll create a follow-up issue for that.

I think that's what I had originally fixed, but not able to check at the moment