Is this named right? It looks like it seeing if there is nothing here through the check against undefined? As if it is saying "doesFieldNameNotExist"?

Some pointers/nits (nothing to hold this up), I would still suggest we follow the flow of most of the code base looking at == null rather than something as specific as undefined since == null will catch both null and undefined values. Most of the other plugins and core code base typically follow that pattern.

I would also use a .some vs. a .find() === undefined if that makes more semantic sense within arrays. Most of the times these days I rarely find a reason to use a for loop instead of one of the more semantic array methods such as .some, .every, .map, .reduce, .flat. etc.... I still sometimes need to use a .forEach or for of but I almost always use it as a last resort and try to see if there's a more semantic loop from the array that makes sense first.

Even looking above this at the loops above it, I mentally rewrite it in my mind as a series of .some() loops as it seems to be doing a series of loops looking for the first entry to become true to return true but if it cannot find it, then it returns false.

For pure functions, I would be careful of introducing functions within functions. They're harder to isolate and test vs pulling the function out and then testing outside of the original function. Since they're pure functions, I don't really worry about other people calling them if they want to as it doesn't have side effects.

Although we don't have strict linter rules around ES2015+ style fat arrows vs. function names, I would stick to one style within a file when you can and use for example the ES2015+ style.

I still recommend to define the return types within TypeScript for functions as it makes it easier to keep other maintainers from accidentally introducing a new return type by accident.

It seems from all the uses of onConfirm that the boolean argument is always present, do we need the ??

Nit: Might be able to just clean up a bit and add the alertData check within retrieveAlertOsTypes so if someone else later uses it they don't need to remember to make this check?

Thanks for adding these!

Should this be formatOperatingSystems?

entries gets defaulted to empty array, does Typescript show an error without the ?? [] because then I'm wondering if we missed something somewhere.

since we type CreateExceptionListItemSchema as a potential type within the array, it's doesn't hasn't been defaulted yet

Ah, gotcha. Is this being used to check exceptions created within the builder? If that's the case I would type it to ExceptionsBuilderExceptionItem[]. That uses ExceptionListItemBuilderSchema | CreateExceptionListItemBuilderSchema and CreateExceptionListItemBuilderSchema is

xport type CreateExceptionListItemBuilderSchema = Omit<
  CreateExceptionListItemSchema,
  'meta' | 'entries'
> & {
  meta: { temporaryUuid: string };
  entries: BuilderEntry[];
};

But I guess, that's only if it's being used in the builder.

Nah, only being used in both versions of the exception modals so it's usually being passed that exceptionItemsToAdd we define with the same Array<ExceptionListItemSchema | CreateExceptionListItemSchema> type in component state

Super nit: I see sometimes we check for falsiness using ! and other times we do === false, is there a specific reason for one over the other throughout? Same with checking for true. I think I've noticed that in the codebase when wanting to check if something exists we use != null to check for both null or undefined. That way when I see someone use ! I usually assume that value is a boolean.

Nit: I might make this explicit and remove the ?