Hello — thank you for Spark.js, the SplatMesh API composes very cleanly into a @react-three/fiber + @react-three/xr scene graph and the docs were a pleasure to follow.
We're a WebXR insurance-inspection application (ClaimSight, XRCC '26 finalist) evaluating Spark.js adoption against an existing R3F + XR v6 stack. We hit one friction point during install that we believe is a small upstream tweak rather than a downstream code change, and wanted to flag it.
Observation
@sparkjsdev/spark@2.0.0's package.json declares:
"peerDependencies": {
"three": "^0.180.0"
}
Under npm semver, the caret for a 0.x.y major-zero package resolves to >=0.180.0 <0.181.0 (caret on 0.x.y is restrictive — only the patch range floats). The effective range is a single minor.
Our application has three@^0.183.2, which puts us outside that range. npm install @sparkjsdev/spark fails with ERESOLVE. We worked around it locally with --legacy-peer-deps, but that side-effect-removed @webspatial/core-sdk (a transitive peer of another dep we use) and required a manual repair — small but indicative of how a single restrictive range cascades.
Spark's docs (docs/docs/0.1-2.0-migration-guide.md and docs/docs/new-spark-renderer.md) both state the minimum required three.js version as r179:
"The minimum THREE.js version required is r179."
That's a wider claim than the actual peer-dep declaration enforces. The published 2.0.0 peer-dep is effectively 0.180.x only.
Request
Would you consider widening the peer-dep to:
"peerDependencies": {
"three": "^0.180.0 || ^0.181.0 || ^0.182.0 || ^0.183.0"
}
(Or whatever ceiling reflects the upper bound you're comfortable supporting — ^0.183.0 is the current three release as of this writing.)
Why this is likely safe
The Spark API surface we exercise — SplatMesh, SparkRenderer, the Object3D scene-graph integration, WebGLRenderer consumption, BufferGeometry interop — is in the most stable part of three.js's public surface. The 0.180 → 0.183 range introduces no breaking changes to any of those primitives (per the three.js changelog), and the existing Spark CI matrix could be widened with low risk.
We also empirically verified composition works end-to-end on three@0.183.2 against a Quest 3 in immersive-ar (lazy-loaded SplatMesh + SparkRenderer rendering a butterfly.spz alongside R3F + @react-three/xr v6). The render path is GREEN; the only friction is the install-time semver gate.
What we'd happily contribute
Happy to send a PR if helpful — a one-line package.json change plus a CI matrix entry. Let us know if a PR or a maintainer-side bump is preferred.
Thanks again for the project.
Hello — thank you for Spark.js, the SplatMesh API composes very cleanly into a
@react-three/fiber+@react-three/xrscene graph and the docs were a pleasure to follow.We're a WebXR insurance-inspection application (ClaimSight, XRCC '26 finalist) evaluating Spark.js adoption against an existing R3F + XR v6 stack. We hit one friction point during install that we believe is a small upstream tweak rather than a downstream code change, and wanted to flag it.
Observation
@sparkjsdev/spark@2.0.0'spackage.jsondeclares:Under npm semver, the caret for a
0.x.ymajor-zero package resolves to>=0.180.0 <0.181.0(caret on0.x.yis restrictive — only the patch range floats). The effective range is a single minor.Our application has
three@^0.183.2, which puts us outside that range.npm install @sparkjsdev/sparkfails withERESOLVE. We worked around it locally with--legacy-peer-deps, but that side-effect-removed@webspatial/core-sdk(a transitive peer of another dep we use) and required a manual repair — small but indicative of how a single restrictive range cascades.Spark's docs (
docs/docs/0.1-2.0-migration-guide.mdanddocs/docs/new-spark-renderer.md) both state the minimum required three.js version as r179:That's a wider claim than the actual peer-dep declaration enforces. The published 2.0.0 peer-dep is effectively
0.180.xonly.Request
Would you consider widening the peer-dep to:
(Or whatever ceiling reflects the upper bound you're comfortable supporting —
^0.183.0is the currentthreerelease as of this writing.)Why this is likely safe
The Spark API surface we exercise —
SplatMesh,SparkRenderer, theObject3Dscene-graph integration,WebGLRendererconsumption,BufferGeometryinterop — is in the most stable part of three.js's public surface. The 0.180 → 0.183 range introduces no breaking changes to any of those primitives (per the three.js changelog), and the existing Spark CI matrix could be widened with low risk.We also empirically verified composition works end-to-end on
three@0.183.2against a Quest 3 inimmersive-ar(lazy-loadedSplatMesh+SparkRendererrendering a butterfly.spz alongside R3F +@react-three/xrv6). The render path is GREEN; the only friction is the install-time semver gate.What we'd happily contribute
Happy to send a PR if helpful — a one-line
package.jsonchange plus a CI matrix entry. Let us know if a PR or a maintainer-side bump is preferred.Thanks again for the project.