Skip to content

Widen three peer-dep range to include 0.181 / 0.182 / 0.183 #345

@sushidoescode

Description

@sushidoescode

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions