Contributor Notes
Just thought I'd put a few notes here.
The goal is always to write as little duplicate code as possible, but sometimes this is difficult, so we shouldn't get overwhelmed by it. Patterns which show up a lot should be made into a helper function. I've already introduced a few of my own. When helpers get used in a lot of places, they should be put in a utils file.
In applications with a lot of business logic, I often end up writing classes which have a new instance for each request, like class ServerEmail { constructor (private state: StateObject) {} }. Usually this is because a set of related functions need some extra information about the request, and keeping that state wrapped in a class with a bunch of related methods is usually cleaner than passing the state object around between a bunch of related functions.
This also makes it easier for features to call each other when necessary, because they always start with a predictable request state and anything extra they need is provided to the constructor along with the state.
I've found it works best to keep Typescript pretty strict, and I'm hoping we can keep it that way. I'm mostly looking for parity between run-time and "type-time", but I'm entirely open to suggestions on this. If everyone is feeling too restricted by something we can always look at changing it as long as it doesn't introduce needless inconsistency.
Typescript has no concept of arguments that are a specific number of places from the end of the argument list. In JavaScript people often like to put optional arguments in the middle, with a required options object on the end. Typescript basically does not support this at all. It can be done, but it's not fun.
So please, don't use arguments that change position. If you need to make it optional, either put it at the end, or allow undefined for the type. Please don't use overloads to try to support the same argument at three positions. It makes keeping the function body properly typed with the arguments so much more difficult and time-consuming than it otherwise needs to be. It only really works when you're writing d.ts files for JavaScript. Typescript code REALLY doesn't like it.
I do know the pain of writing something("value", undefined, undefined, undefined, () => {}). But that is still so much easier than amount of type-shenanigans that floating arguments require. And most of the time, having a single object argument with a bunch of optional properties is the best solution.
(this is real)