Remove options initializer (BETA)

[cristobal]

There is no need to have the options initializer, since it will already be initialized by the default parameter in the function should undefined be provided.

This is dead code that never will incur.

[frederikprijck]

According to mdn, we do need this.

Default function parameters allow named parameters to be initialized with default values if no value or undefined is passed.

Null is neither undefined or not a value, so that would not use the default.

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/default_parameters#passing_undefined_vs._other_falsy_values

[cristobal]

Yes 🤦🏽

[cristobal]

Still the why for this PR here is that the type defintions do not allow for null as an input value to the function. It should either be an object or undefined.

Yes people can still call with null if they want when in environments where they are not using code completion.

Dunno an alternative here would be to assert for null an throw an error If that’s the case, since the type definitions are either expecting an object or undefined.

[cristobal]

Or perhaps it would be better to just have options?: JwtDecodeOptions, then the default initializer statement is more explicit on why it's there as it's now it's a bit confusing.

Created a PR on this #179

[jonkoops]

Yes people can still call with null if they want when in environments where they are not using code completion.

This is always possible, there should be no need to check for this. If folks want to be type-safe they can opt in to TypeScript. Otherwise we'd end up with a bunch of defensive code that is shipped to all users (some of which already exists).

[frederikprijck]

Closing, as I believe we want to keep this. Even though I agree with what @jonkoops said, the code allowed for null to be passed so let's keep that.