I generally would return some reasonable identity object for such cases than raising sloppy errors.
Maybe null can be reasonable.
Or otherwise, it may be useful to denote the types as [BufferGeometry, ...BufferGeometry[]] instead of BufferGeometry[],
where typescript can just warn users that users should pass array with at least one element.
three.js will tell you to validate your inputs, so this is working as intended there. I do agree with your solution, but would prefer to not change the type (rather than adding a runtime guard).
three
version: 0.160@types/three
version:three-stdlib
version:Problem description:
mergeBufferGeometries
gives errorUncaught TypeError: Cannot read properties of undefined (reading 'index')
It is from some sloppy list accesshttps://github.com/pmndrs/three-stdlib/blame/45e22a1b636241147934e8bd9f22d506ccfc3cf0/src/utils/BufferGeometryUtils.ts#L27
which also exists in
three.js
upstreamhttps://github.com/mrdoob/three.js/blob/de6dd45d7e5aa58fed0fbc1dbe53def3402b39cc/examples/jsm/utils/BufferGeometryUtils.js#L109C20-L109C51
Relevant code:
Suggested solution:
I generally would return some reasonable identity object for such cases than raising sloppy errors. Maybe
null
can be reasonable.Or otherwise, it may be useful to denote the types as
[BufferGeometry, ...BufferGeometry[]]
instead ofBufferGeometry[]
, where typescript can just warn users that users should pass array with at least one element.