gcode-preview icon indicating copy to clipboard operation
gcode-preview copied to clipboard

Update threejs version

Open TimTheBig opened this issue 5 months ago • 4 comments

Update threejs version maybe with a >= requirement for future proofing and better resolving.

TimTheBig avatar Sep 01 '25 15:09 TimTheBig

Threejs doesn't use semver so there isn't really a simple way to know which version is compatible. But you have a good point.

Maybe using an explicit range is a good idea: https://elliott-king.github.io/2020/08/package_json_symbols/#hyphen

What do you think?

remcoder avatar Sep 02 '25 10:09 remcoder

I am not comfortable only having a minimum version and letting people update Three.js at their own risk. Since it's not using semver, pretty much each version can have breaking changes. Not all of them will affect this library, but let's keep in mind:

  1. Our test suite will not catch everything. We have to do some manual testing to validate the actual rendered result. It can take a while before an issue is caught with newer versions, fixed, and published.
  2. We have SaaS products depending on this lib and we don't want to let them break so easily
  3. We also have hobby projects by inexperienced devs that would have a hard time figuring out why something is broken

A range is the safest in my opinion, but there are some safeguards we'd need to put in place.

In order to identify breaking changes we need to fix when a new version of Three.js comes out, we need CI to run on the maximum version when we bump it. Again, it will not catch everything, but it can help with method removals. When we open the PR to bump the maximum version, we'll probably see the deprecation warnings and we can open github issues for them to facilitate the next version bump.

We also need CI to run on the minimum version we set, to make sure we don't introduce dependencies on later versions of Three.js without bumping the minimum version.

This can be done configuring a matrix strategy: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations

sophiedeziel avatar Sep 02 '25 20:09 sophiedeziel

Good points!

I just realized we have a lower bound already as per #212, setting it at r166. But this needs to be doublechecked. And since Threejs is at r179, while we are now at r178, that can be checked too.

So proposing to set compatibility at:

  • [ ] r166-r179 (after checking)
  • [ ] then use the matrix strategy in CI to run build and test scripts at those bounds

Sounds good?

remcoder avatar Sep 02 '25 20:09 remcoder

That seems like the best solution

TimTheBig avatar Sep 05 '25 18:09 TimTheBig