ReactAreaLights do not seem to work in a module bundler

[drcmda]

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

[Mugen87]

it looks like this file: https://github.com/mrdoob/three.js/blob/master/examples/jsm/lights/RectAreaLightUniformsLib.js is mutating a namespace.

I'm not sure I understand. Can you please explain in more detail what you mean?

It seems to work fine in the official example:

https://threejs.org/examples/webgl_lights_rectarealight

[drcmda]

PS. i have included a console.log right after the init() function, which writes ltc_1 and 2 into the shaderlib. both ltc_1 and 2 are undefined, because three/Shaderlib and three.module/Shaderlib are two separate modules.

i think this is actually worse, i hope i'm wrong but i believe that any project right now that relies on examples/jsm pulls two full threejs bundles.

It works if you do:

import * as THREE from 'three/build/three.module'

but that's no solution because 100% of all three extension in the eco system pull from 'three'.

[Mugen87]

i think this is actually worse, i hope i'm wrong but i believe that any project right now that relies on examples/jsm pulls two full threejs bundles.

I think this is not true. As you can see at the following repository, you can perform ES6 imports like so...

import {
	BoxBufferGeometry,
	Mesh,
	MeshBasicMaterial,
	PerspectiveCamera,
	Scene,
	WebGLRenderer
} from 'three';

import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js';

...and the resulting bundle (created with rollup) does not contain multiple version of three.js. https://github.com/Mugen87/three-jsm

It seems to me you are doing something wrong in your build or at codebox.

[Mugen87]

Related: https://discourse.threejs.org/t/jsm-modules-for-browser-double-import-with-typescript/8235

[drcmda]

this happens in all bundlers i've tried. create-react-app, webpack, codesandbox, parcel, etc. it imports from a namespace that differs from "three", so these mutations end up in another space.

your example works because rollup happens to pull from three.module via package.json:jsnext:main/module. 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.

jsm/examples like a normal eco system lib. it should refer to "three", not cling to a particular build file. this is the root cause and it's definitively not correct. is there any reason why it does that, though?

[Mugen87]

your example works because rollup happens to pull from three.module via package.json:jsnext:main/module. 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.

I think rollup does it the correct way and fetches three from the intended location (like configured in package.json). I'm not familiar with the other bundlers but I suppose it's a matter of configuration.

is there any reason why it does that, though?

three.js is not a pure node.js project. It's intended that you can directly load modules in HTML pages like in the official examples. If we would load modules from 'three', a dependency resolution is not possible.

[njarraud]

I do not understand the issue either. I use the node system located in examples/jsm and build my app with webpack. Everything works as intended and I do not have any problem of double threejs import.

[drcmda]

@njarraud im more concerned with react area lights. you can see in both demos above that it doesn't work. webpack has the same problems once it pulls from main.

three.js is not a pure node.js project. It's intended that you can directly load modules in HTML pages like in the official examples. If we would load modules from 'three', a dependency resolution is not possible.

this is a real problem. i think this lib should work with the tools that everyone uses (npm). but relying on a particular dist file is not good practice in general. it works in that html file now, but it impacts the usefulness of jsm. also, just like that the commonjs export is incompatible with examples/jsm.

[drcmda]

tried to search through sources,

html demo

bundled

as i suspected it pulls both three.js and three.module.js and creates two namespaces. you can assume this has silently happened in every bundling system that doesn't follow the module field.

i think it could also at least affect the html demos if they pull threejs 3rd party npm packages, which all resolve "three".

[njarraud]

this is a real problem. i think this lib should work with the tools that everyone uses (npm).

The reason I like and use threejs is because it doesn't depend on any particular third party platform like Nodejs. That is a strength from my point of view.

I'll check if I have an issue with ReactAreaLights as well.

[drcmda]

doesn't depend on any particular third party platform like Nodejs. That is a strength from my point of view.

That still does not make it OK to break it for the all the people that use it. Standard imports are still arguably useless, as is evident by this very issue: it couldn't just use "three". Spec imports depend on a build system because they don't have a resolution concept yet. But in any case, the root cause is a misunderstanding of how modules behave. Linking a distro file isn't something you would do, bundlers or spec imports.

[njarraud]

That still does not make it OK to break it for the all the people that use it.

It doesn't make it OK either to break it for people who don't use it. I leave it to @mrdoob and the other three.js guys as they are definitely more qualify than I am to answer you concerns.

[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?

[drcmda]

@gkjohnson Here's the statement from Ives, he made csb: https://twitter.com/0xca0a/status/1159954977672105984

It's up to the bundler to decide which it pulls and both module/main are permissable. If a library on the other hand imports from "three/build/three.module", that is not correct, we're skipping resolution now. all bundlers that follow main will have two bundles and all interop will break. this will also happen in webpack. that is the reason we have these fields in package.json in the first place, for resolution.

i think it's the demos that have to be adjusted, not the module standard as it stands.

in a real world project there would always be labour involved if you want to deal with browser imports, you would have a dependencies folder inside source and any package you use has to go at least through rollup to resolve to it. the spec is far from being practicable.