fix(ls): Allow explicit null
value for options parameter
#3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This pull request addresses a type safety issue related to the
options
parameter in allls*
functions.Details
Previously, the
options
parameter for allls*
functions was defined as non-nullable. This meant you couldn't explicitly passnull
as an argument, even though usingundefined
or an empty object ({}
) was a valid way to indicate no options.This change updates the type definition for the
options
parameter to allownull
as a valid value alongsideundefined
. This provides more flexibility in how you can use thels*
functions.Previously if you write code like this:
An error will be thrown from the internal function, with message
Uncaught TypeError: Cannot read properties of null (reading 'match')
. Now after this change, the issue has been fixed and can theoptions
parameter is now nullable.Benefits
The type definition now accurately reflects the acceptable values for the
options
parameter.Developers can now explicitly pass
null
to indicate no options, leading to clearer code and potentially fewer runtime errors.