feat: Convert event_processor_config_validator to TS

[yavorona]

Summary

Convert the last utils module event_processor_config_validator from JS to TS.

Test plan

Existing unit tests

[yavorona]

Even though isSaveInteger would take care of checking the eventBatchSize type, we still need this additional type check here to avoid compiler error. Same condition applies on line 36 in validateEventFlushInterval method.

[mikeproeng37]

For these validations, we should rely on TS to validate the type. For example, wherever we take in the batchSize input, we should make the param type a number. That way we can guarantee that it is always a number. Then this method would only validate that the number is within a safe range.

[mjc1283]

@mikeng13 I agree in general, but batch size is passed in by the caller which could be plain JS. At some place (either here or at a higher level), I think such values must be represented as unknown, have the type checked at runtime, and then can convert to number.

[mjc1283]

@yavorona Would using type guards be helpful here, or in other validator functions? Maybe it would help with control flow and avoiding unhelpful compiler errors in the callers of these validators.

[mikeproeng37]

Ah yeah that is a fair point.

[yavorona]

@mjc1283 isn't a typeof eventBatchSize === 'number' already a type guard? Another way I can think of is to use type predicate, which would look like this:

const validateEventBatchSize = function(eventBatchSize: unknown): boolean {
  if (isSafeInteger(eventBatchSize)) {
    return eventBatchSize as number >= 1;
  }
  return false;
}

Let me know what you think!

[coveralls]

Coverage increased (+0.003%) to 96.693% when pulling 5a9ffc3 on pnguen/convert-event-processor-config-validator-to-ts into 28260a2 on master.

[yavorona]

Went back to default export object to avoid issues with stubbing validateEventFlushInterval and validateEventFlushInterval.

[mjc1283]

LGTM. I added a suggestion about type guards. Perhaps that would be useful when entry points, or modules calling validators, become TS.

[mjc1283]

@mikeng13 I agree in general, but batch size is passed in by the caller which could be plain JS. At some place (either here or at a higher level), I think such values must be represented as unknown, have the type checked at runtime, and then can convert to number.

[mjc1283]

@yavorona Would using type guards be helpful here, or in other validator functions? Maybe it would help with control flow and avoiding unhelpful compiler errors in the callers of these validators.