chore: enable no-explicit-any rule as error level #1366
Conversation
Removes our override such that `any` is no longer allowed, and replaces usages of it.
wooorm
left a comment
There was a problem hiding this comment.
As for “so while we do let you set whatever you want in setSourceCodeLocation, it doesn't make much sense to set anything that isn't a Location, as you need to get that back out in getSourceCodeLocation anyway.”
This project predates typescript, and also not every javascript user uses typescript. So would an alternative approach also be possible: to make the types match javascript?
Not everyone will understand the usage of `never` here, so we can continue using `any` instead and ignore the linter.
the parser assumes similarly, update/set are passed an these are not in question and have the right types. however, so, for this test to work as it used to, it'd need its own |
Removes our override such that
anyis no longer allowed, and replaces usages of it.@fb55 this uncovered a curiosity:
the
Updating node source code location (GH-314)test was basically asserting that you can have a custom source code location setter. i.e. you can have your own location shapehowever, we have a strong type for
Locationand all tree adapters are required to return anElementLocationfromgetSourceCodeLocation(which itself is aLocation).so while we do let you set whatever you want in
setSourceCodeLocation, it doesn't make much sense to set anything that isn't aLocation, as you need to get that back out ingetSourceCodeLocationanyway.tldr i think the test and the use case made sense way back, but has lost its meaning as we've strengthened types