There's a paradigm called duck typing that says (from Wikipedia):
In duck typing, a programmer is only concerned with ensuring that
objects behave as demanded of them in a given context, rather than
ensuring that they are of a specific class. For example, in a
non-duck-typed language, one would create a function that requires
that the object passed into it be of type Duck, or descended from type
Duck, in order to ensure that that function can then use the object's
walk and quack methods. In a duck-typed language, the function would
take an object of any type and simply call its walk and quack methods,
producing a run-time error if they are not defined. Instead of
specifying types formally, duck typing practices rely on
documentation, clear code, and testing to ensure correct use.
I would focus on the following part of above text:
In a duck-typed language, the function would take an object of any
type and simply call its walk and quack methods, producing a run-time
error if they are not defined
And...
[...] duck typing practices rely on documentation, clear code, and testing
to ensure correct use.
That is, since JavaScript is a dynamically-typed language fits very well with duck typing.
In other words, you should avoid these tests. If a module has a missing property or it exists with an undesired type, you'll get a runtime error, which is enough to note that the caller doesn't fulfills the implicit contract to work fine with a given module.
The whole contract defined by the behavior of your code during run-time can be enforced by good documentation pages.