My recommendation for APIs that have optional parameters is to have an optional last options parameter, every property of which can be left unset. Makes it far clearer to the caller what those properties do.

When null can be handled rationally, a library should accept it and do something reasonable.

When null makes no sense whatsoever, a library should error out if it receives null.

So it’s up to your use case which is most appropriate.

The core principle is the program should stop executing the moment we 100% know that we’re not going to accomplish what the user needs. In many cases, being passed ‘null’ tells us that.

In any other case, the program should pick a reasonable (default) option for the user and continue running.

Having to pass in null values seems a bit weird. You can define functions and optional parameters like this:

function myFunction(a = 1, b = 1, c = null, d = null, e = true) {
  return a * b;
}

Then people don’t have to call your function with

myLibrary.myFunction(1, 7, null, null, true);

they just call your library with

myLibrary.myFunction(1, 7);

You could add a default inside the method signature, like:

function myFunction(a = 1, b = 1, c = null, d = null, e = true) {
  if (c === null) {
    c = 5;
  }
  return a * b * c;
}

because if you define it in the method:

function myFunction(a = 1, b = 1, c = 5, d = null, e = true) {
  return a * b * c;
}

then if people still call it with

console.log(myFunction(5, 2, null));

Then the default c = 5 is overwritten by null, and results in 0.

I don’t know if you really need to handle all that though, instead of just doing c = 5 - if people intentionally call your library with null, and things go wrong…? well yea ok, don’t do that then.

But it depends on the use-case. If this is some method deep within a library, and some other calling method might be unintentionally dumping null into it, you could default it inside the method, and handle it