I could've updated the README to have null changed to undefined instead, but some people(including me) prefer passing null as an argument for an optional parameter.

I had another idea to make use accept a single param with the following typescript interface

interface AxiosInterceptorUseParams<V> {
  onFulfilled?(value: V): V;
  onRejected?: (error: any) => any;
  options?: AxiosInterceptorOptions
}

But that would've been a major breaking change, so I just incorporated the null type for now

Actually, I am incorrect, any in this instance cover null too? Let me know if I have it wrong but I am closing for now.

Hi @jasonsaayman
Thanks for the response. You may want to try this out with strictNullChecks or strict set to true in tsconfig in your IDE and you'll surely get the type error I mentioned in the PR description. Type definition currently clearly specifies that these can either be a function or undefined(because them being optional).
You can also refer to https://www.typescriptlang.org/tsconfig#strictNullChecks
According to the docs

When strictNullChecks is false, null and undefined are effectively ignored by the language. This can lead to unexpected errors at runtime.
When strictNullChecks is true, null and undefined have their own distinct types and you’ll get a type error if you try to use them where a concrete value is expected.

If you still have any concerns, please reach out, I'd be quick to respond 👍

I will do, adding myself to this for now