In the main repo this should be formatted like this:

expect(
  spellCheckSuggestionSpans!.length,
  equals(misspelledWordRanges.length),
);

And same for several other places where the closing parenthesis is on the same line but should be on the next line.

Maybe this kind of stuff is not enforced in integration_tests though?

Also if spellCheckConfiguration is null itself then spell check is disabled, right? Maybe consider mentioning that here.

Is this the way that we typically update all of these pubspec.yamls and everything? Maybe @cyanglaz knows? I just want to double check that it's ok/normal to check in all of these pubspec.yaml updates when modifying the integration tests and stuff. Some of them seem like they might be unrelated to this PR, if it matters.

@cyanglaz I would also like confirmation of this. I've been using flutter upgrade-packages as per an error message I got.

I thought that last sentence of this paragraph is false? spellCheckService and spellCheckSuggestionsHandler will get default values if they are null.

This comment was to address your comment above, which is to note that if the configuration itself is left null, then spell check will be disabled, which is true. That will change when spell check is enabled by default, though.

Can this be derived from the state rather than saved? For example, maybe this could be a getter that looks at widget.spellCheckConfiguration to determine its return value. That way we don't have to worry about this value ever being out of sync with widget.spellCheckConfiguration.

Without this, the linter throws avoid_classes_with_only_static_members. I played around with moving this code completely to EditableTextState but it felt wonky, since it would be harder for users to access these methods (since keeping them static would not make sense anymore) and it would also be weirder to test. Thought about moving it to one of the SpellCheckConfiguration or SpellCheckResults classes but neither seemed fitting. Also, I think that moving this code out of this class would further commit us to not allowing this handler to be configurable, and I don't believe that is desirable.

What if you get rid of the class and just make these top level functions? Kind of like showMenu I guess.

What are you goals for making this configurable as you say? Currently buildTextSpanWithSpellCheckSuggestions can be reused in places other than EditableText (maybe like a custom text editor?) but EditableText's usage of it can't be configured.

I think making them top level functions makes sense. I actually was pro-moving them out of their own class 😅 I think I just overthought the impact of moving the methods out of their own class.

This looks like a leftover merge artifact. It looks like it is causing several of the test failures

Here too