ReactAreaLights do not seem to work in a module bundler

Description of the problem

basically, area lights do not work with npm/node module resolution, see:

simplified: https://codesandbox.io/s/three-fibre-userender-test-rohv5

raw threejs arealight demo: https://codesandbox.io/s/dreamy-platform-3jpim

why

all files under examples/jsm pull from ../../../build/three.module.js instead of three, which is arguably not correct. it will pull threejs two times in bundling systems that do not follow package.json:module (but “main” instead, which leads to build/three.js). it then creates two separate namespaces. uniforms.init() ends up writing to the wrong one.

solution

this is how a typical jsm file should look:

import {
	ClampToEdgeWrapping,
	DataTexture,
	FloatType,
	LinearFilter,
	NearestFilter,
	RGBAFormat,
	ShaderLib,
	UVMapping,
	UniformsLib
} from "three";

that’s how any other library works. i have never seen library that relies on a distro file - this has obvious pitfalls. i understand that this was made to make the html demos work, but imo this is a hack, and it now impacts production usage.

Three.js version

• r107

Browser

• Chrome

OS

• macOS

[looeee]

I’m sure this is what you meant but just to be clear the cjs examples should be able to be used universally when bundling three.js in an application with any of these tools.

Well, yes, if you tell a tool to import a cjs file then it should do that. It’s also fine for tools to import cjs using import * as - it seems like that’s violation of the spec, but it’s very convenient and common.

But if there is ambiguity, then a tool should always default to the es6 module when using import and always default to cjs when using require. For example, import * as THREE from 'three' is ambiguous since it’s not telling the bundler exactly what file to use. But it’s using import so it should always choose three.module.js if available. If you want cjs via an import statement then you should have to specify it using import * as THREE from "three/build/three".

If a bundler doesn’t do this then you have a situation where this:

import * as THREE from "three";
import { OrbitControls } from "three/examples/jsm/controls/OrbitControls.js";

which is 100% correct es6 code, leads to wrong results. And that’s just crazy and frustrating.

The only thing I’d say is ‘wrong’ here is when a person or bundler uses cjs and es6 from the same npm package. Of course that’s still a relative statement and if it works in your project then great. But doing that is what’s causing all the confusion here. Since codesandbox is not a private app then it seems like they should be more responsible and at least warn people they are importing cjs even though an es6 module is available.

[gkjohnson]

I’m using webpack with babel, react, three.js, and a variety of three.js example modules and I’m not seeing a any duplicate threejs bundles included. I set up two small example builds using rollup and parcel and both seemed to work just fine, as well.

if it would follow “main” or fetch three from source, you would have two threejs versions in the output and arealights would also not work.

Can you describe the setup you’re using such that the build process is using the build pointed to by package.json “main”? And by fetching from source do you mean pointing to the “src/Three.js” file? My experience is that the bundlers prioritize the “module” field over “main” so I wouldn’t expect that this would be a problem.

I expect that the solution won’t be to immediately change all the example scripts over to import from “three” because that would break quite a few things – maybe we can talk about solutions that afford both use cases instead?