Cannot set property ACESFilmicToneMapping of #<Object> which has only a getter

[drcmda]

For a long time threejs had trouble with commonjs environments, see #17220 It affects all jsm files that mutate the namespace, ReactAreaLights for instance.

A dirty workaround existed:

import * as THREECJS from 'three'
import * as THREE from 'three/build/three.module'
Object.assign(THREE, THREECJS)

It works around threeejs broken module resolution by merging the two namespaces that it creates into one. (And yes, using threejs+jsm in cjs currently loads two versions of the same library with two separate namespaces). But something in threejs took that away recently:

Cannot set property ACESFilmicToneMapping of #<Object> which has only a getter

sandbox: https://codesandbox.io/s/three-fiber-useloader-rohv5?file=/src/index.js:0-103

Could threejs please remove cjs? By offering "main": "build/three.js" it appears as if it does support cjs, but jsm most definitively doesn't, since it refers to three/build/three.module.

I don't understand for whom that cjs file is for tbh. You can't use any third party lib or add-on reliably, including examples/jsm - and in every case you're loading threejs twice. Why would anyone want this? It's causing so much trouble, i can't count the bug tickets i get b/c of this. It would be such a relief to see that file go, or at least the entry in package.json.

[donmccurdy]

This isn't a great answer, but for what it's worth, the jsm/ folder was never meant to be used with CJS. The js/ folder is more compatible with CJS than the jsm/ folder. For example:

const THREE = global.THREE = require('three');
require('three/examples/js/loaders/GLTFLoader.js');

const loader = new THREE.GLTFLoader();

I realize the reliance on global scope there is not ideal, and may cause issues with some bundlers, but this approach has worked for many CJS-based projects.

---

Longer term — please be aware that we may remove the examples/js folder, perhaps around end of year. I believe (but this is still an area of discussion) that would mean no longer offering CJS support — use of ES Modules would be required. Maintaining multiple versions of the examples/js(m) packages is time-consuming, far more so than maintaining CJS/ES versions of the core library, and doesn't seem sustainable with the current approach.

[drcmda]

This isn't a great answer, but for what it's worth, the jsm/ folder was never meant to be used with CJS.

The problem isn't so much the cjs, but the module resolution. you can't offer two namespaces but then import one relatively in add-ons - that is the root cause for so many problems down the line.

today it caused half of the codesandboxes we offer to go down (deps probably not pinned, who knows what did it) , tomorrow it will be something else.

please be aware that we may remove the examples/js folder, perhaps around end of year. that would mean no longer offering CJS support

That would really be the end of all woes! That day can't come soon enough. Anything that helps the current module situation is very welcome. :-)

[mrdoob]

I thought we already discussed this in the past and we agreed that this was an issue with codesandbox not using the "module" field in package.json when they should.

[Mugen87]

Marking this as a duplicate of #17482 then.