Closed wiese closed 2 years ago
Good idea, I can add this pretty quickly. I think it makes more sense in output than input - partly because requiring tuples in input can lead to annoying type errors, and partly because e.g. polygonToCells
might use GeoJSON as input, which can technically include a third element in coords for altitude (though the H3 library would ignore it at present).
...I took a quick swing at this, and ran into the same issue noted in the discussion you linked. The problem is, JSDoc doesn't technically support tuples, leading tsd-jsdoc
to fail when trying to parse them, so we can't easily support tuples unless we switch from auto-generating types with tsd-jsdoc
to another approach (hand-crafting the libdef, or converting the underlying code to TS and generating the libdef from there). I'll take a quick look to see if there's an alternative generated solution here, but otherwise I'm less willing to change the whole type generation approach to fix this issue - sorry about that.
converting the underlying code to TS
Would such a change be something we could do? I'd be in for it.
converting the underlying code to TS
Would such a change be something we could do? I'd be in for it.
I have an alternate option here (#153) generating the .d.ts
files with TS. It's a little awkward but solves this issue. Converting to TS should be feasible, but I think it would require re-engineering the build, which could be a pain. I'd be open to PRs for this, as long as they create all the same bundles we do now.
Many methods (e.g.
cellToLatLng()
) return a tuple of latitude, longitude.They are documented as returning a variable-length array of numbers (
number[]
), while in practice they should return a fixed-length array.Is there a reason not to document this as
[number, number]
instead? This could help in TS projects with strictly configured index access.Thanks
Further reading