Getting the following error while building a react project in azure DevOps pipeline (able to build the project locally, pretty sure we didn’t change the dependencies):
./node_modules/three-stdlib/loaders/KTX2Loader.js
Attempted import error: 'Date3DTexture is not exported from 'three'.
@react-three/drei: “^8.8.3”,@react-three/fiber: “^7.0.26”,Can anyone please help? Thanks!
It looks like three-stdlib requires three.js r138 or higher, if you are using KTX2Loader. The Data3DTexture class was renamed from DataTexture3D in r138. Add new render target types for 3D and array textures. by Mugen87 · Pull Request #23498 · mrdoob/three.js · GitHub
Thanks, @donmccurdy, we fixed it by upgrading three to 0.143.0. Though we don’t use KTX2Loader in our code. Cheers!
oh that’s unfortunate that the bundler doesn’t ignore it. i think in dev mode it doesn’t tree-shake yet, only in production. but if updating worked that’s great!
Thanks @tirth.patel.ss I can confirm this happens, and that bumping three to 0.143.0 fixes the issue
I was getting this exact error, then I upgraded my three version to 0.143.0 after that I started getting the following error
./node_modules/three-stdlib/objects/MarchingCubes.js
Attempted import error: 'NoColors' is not exported from 'three'.
Please Advise!
Updating to r138 gave me this error
Please help!
if this is trying to import the tsx files directly something is wrong in how you’re using it. it’s just
import { MeshReflectorMaterial } from '@react-three/drei'
the library is a transpiled flat bundle, the source is not being used for production.
I am facing a similar problem. I have upgraded Threejs to r149, the latest one but it’s still not resolved.
Error: ./node_modules/postprocessing/build/postprocessing.esm.js
Attempted import error: ‘DataTexture3D’ is not exported from ‘three’ (imported as ‘DataTexture3D2’).
package.json:
“@react-three/drei”: “^9.56.17”,
“@react-three/fiber”: “^8.10.4”,
“@react-three/postprocessing”: “^2.7.0”,
“@types/three”: “^0.149.0”,
“react”: “^17.0.2”,
“react-dom”: “^17.0.2”,
“react-scripts”: “4.0.3”,
“three”: “^0.149.0”,
“three-stdlib”: “^2.21.8”,
appreciate any help, thanks!
until it’s clear how to proceed best go down to three 148 and it will work. three is pushing out breaking changes in semantic patch versions, it kind of makes a mess.
postprocessing will now be forced to release a major version just to correct that naming change and target three >= 0.149.0 in peerDependencies.
three is pushing out breaking changes in semantic patch versions, it kind of makes a mess.
Are you aware that the version bump from 0.148.0 → 0.149.0 is, explicitly, allowed to contain breaking changes according to Semver? Versions below 1.0.0 work differently than versions above it. I understand there’s an ask here for breaking changes to happen less often, but accusing maintainers of not understanding Semver is not really helping.
i wish it had semver, as it is commonly understood, in that it helps to establish project safety. i’ve expressed this often. it’s not to accuse anyone, it’s not a personal matter. three exists for 10 years, or more, < 1 in semver is for alphas and betas during the testing phase, but i find it hard to argue that three is that.
the correct version for 0.149.0 would have been 1.0.0 and that project up there wouldn’t have broken down. would also have given the author time to respond. but projects just … fail. it puts library authors under a lot of unwarranted stress.
If you’re bumping any dependency from 0.(x) to 0.(x+1) then you should expect breaking changes, that is how Semver works in the <1.0.0 range. Whether three.js should still be using version numbers in that range is a fair objection, and certainly makes using three.js as a peer dependency harder yes.
But I don’t think anyone actually wants us to just bump major versions every month. The harder part here is deciding how to coordinate releases so that breaking changes are batched into less frequent major version increments, and that is complex particularly because of the addons directory.
i wonder which end-user wants a package that npm can indiscriminately bump, and then it still breaks.
imo threejs has a problem with priorities. it has a hard time figuring out what’s important: package safety, a heathy eco system, or collected examples.
a good solution would be to sever addons, establish real semver. and it gets a peerDependency range. it would give the eco system some peace, projects would be safe.
npm clients do not automatically bump you from 0.(x) to 0.(x+1), they recognize that represents a breaking change, and treat it the same as a major version bump.
a good solution would be to sever addons, establish real semver. and it gets a peerDependency range. it would give the eco system some peace, projects would be safe.
What’s needed is a clear proposal (e.g. a written RFC). What’s happening is short, scattered, sometimes disparaging comments. This is not something I’m going to spearhead, but I’m willing to support it.
thanks. v148 works!