Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade postprocessing dependency to latest #263

Open
hezzy-cloudinary opened this issue Feb 5, 2024 · 4 comments
Open

Upgrade postprocessing dependency to latest #263

hezzy-cloudinary opened this issue Feb 5, 2024 · 4 comments

Comments

@hezzy-cloudinary
Copy link

We want to use three.js r159 and above but the version of postprocessing used (6.33.3) has a peer dependency of <159.
postprocessing's latest version requires <r162 which is great.

Can you release and upadate using postprocessing's latest please?

@CodyJasonBennett
Copy link
Member

We specify ^6.32.1 which should upgrade to the latest in 6.x.x, so it should automatically work on your end when a version of postprocessing is available for three.

@tux21b
Copy link

tux21b commented Mar 5, 2024

This ticket is valid, there is something to do here:

  • updating "three" from v0.161.0 to v0.162.0 breaks postprocessing (LinearEncoding was been renamed)
  • updating "postprocessing" to v6.35.0 fixes the problem, but "react-postprocessing" still uses the old, broken postprocessing version
  • forcing a newer version of postprocessing (via resolutions in package.json) breaks "react-postprocessing"

"sRGBEncoding" is not exported by "node_modules/three/build/three.module.js", imported by "node_modules/@react-three/postprocessing/dist/effects/Texture.js"

@CodyJasonBennett
Copy link
Member

This is misinformed; none of those points are inherently true. Again, see my prior comment.

I'm trying to release #268 which is pertinent to the quoted stack trace as previous versions of react-postprocessing used known deprecated constants which were removed in three r162.

We can increment the postprocessing version we specify in package.json, but this does not introduce any new behavior other than denying existing installs or overrides people may use to support older three versions as the range has a higher specificity (equivalent to >=). This is a breaking change and why we rely on ^6.x.x resolution.

@tux21b
Copy link

tux21b commented Mar 5, 2024

Thanks @CodyJasonBennett for clearing that up. I can confirm that my analysis was indeed misinformed and the update worked as expected. I am not really sure what was the issue before. Neither renovate (an automatic update bot) nor I were able to update, but now everything works like a charm. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants