Users who are consuming our SDK directly from JavaScript (as opposed to TypeScript)
may attempt to pass in null in various places where we expose undefined in our
APIs. Based on the strict equality checking that we are doing (===), nulls would
not be accepted in those places in the API and would result in errors for the users.
This commit applies some eslint rules that @tvald suggested, which forbid the explicit
use of undefined as a value, and require the less rigid == equality checks for null
(these checks will pass for both null and undefined).
This should allow JS users to pass in null for optional fields in our SDK APIs. I do not
believe there are any backward incompatible changes in this PR, nor any functional changes
other than being more tolerant of null.
Users who are consuming our SDK directly from JavaScript (as opposed to TypeScript) may attempt to pass in
null
in various places where we exposeundefined
in our APIs. Based on the strict equality checking that we are doing (===
),null
s would not be accepted in those places in the API and would result in errors for the users.This commit applies some eslint rules that @tvald suggested, which forbid the explicit use of
undefined
as a value, and require the less rigid==
equality checks fornull
(these checks will pass for bothnull
andundefined
).This should allow JS users to pass in
null
for optional fields in our SDK APIs. I do not believe there are any backward incompatible changes in this PR, nor any functional changes other than being more tolerant ofnull
.