Three.js dev iteration process, bundling has become really slow

[gkjohnson]

Description

I'm not exactly sure when it happened but modifying three.js core and checking the changes in the example files has become really difficult. The changes used to be reflected almost immediately but now it takes several seconds for anything to change resulting in a lack of trust around whether the latest changes are being displayed. And even then once the page does change it initially logs an error that a subfile is not yet available (because it's still being built):

Uncaught SyntaxError: The requested module './three.core.js' does not provide an export named 'UniformsUtils' (at three.module.js:6:1049)

I suspect this is because with WebGPU and TSL there have become 6 build targets that are also built even if not needed during dev.

Solution

• Produce a separate "dev" rollup config that builds what's necessary focused on iteration speed, removing code splitting, multiple build targets.
• Possibly produce a separate dev command for WebGPURenderer and WebGLRenderer if speed continues to be a problem to minimize files being built.
• Import three.js directly from source during development so no build is required.

Alternatives

• Switch to another, faster build process.
• Tolerate unnecessary build delay, lack of trust in dev bundle process.

Additional context

No response

[RenaudRohlinger]

What I do is that I just replace the build path by src and then I get realtime dev environment:

<script type="importmap">
{
	"imports": {
		"three": "../src/Three.WebGPU.js",
		"three/webgpu": "../src/Three.WebGPU.js",
		"three/tsl": "../src/Three.TSL.js",
		"three/addons/": "./jsm/",
	}
}
</script>

[gkjohnson]

I understand there are ad-hoc patches that can be made but we should fix the dev process so it's not so misleading, slow, and error prone for non power users.

[donmccurdy]

Just to make sure we're all seeing similar numbers – time npm run build takes 6–8s for me on an M1 Pro CPU, are you seeing comparable times, give or take any CPU differences?

npm run build 22.19s user 1.41s system 334% cpu 7.053 total

[donmccurdy]

Commenting out the minified builds drops the build time to a pretty consistent 2–2.5s, for me, perhaps we could make that the default and only do minification for production builds. Nervous to disable code splitting, since that might hide mistakes when importing from the wrong place. Using source files in local development could be nice but probably means we can't just use a simple static server anymore.

[Mugen87]

MacMini with M2Pro:

[Mugen87]

IMO, these numbers are okay. Especially since the files used in the examples are build first. I'm not sure this justifies a change in the build system...

[WestLangley]

I use npm run build-module. Thank you for adding that.

npm run build-module 10.77s user 0.80s system 255% cpu 4.523 total

[gkjohnson]

Here's how long it takes for a build to run for me - similar numbers it looks like:

npm run build 23.14s user 1.29s system 295% cpu 8.266 total

By comparison I'm getting around 7-8 seconds for a build in r150 so the build times have more than tripled:

npm run build 7.77s user 0.54s system 204% cpu 4.054 total

---

IMO, these numbers are okay. Especially since the files used in the examples are build first. I'm not sure this justifies a change in the build system...

I'm not sure how you're concluding this. I'm not convinced that the "files used in the examples are build first" since the "three.core.js" file is used by the import from examples and possibly rebuilt multiple times or something. The current time from change to see the changes in the examples is unacceptable and you don't need to look at numbers to experience that dev has gotten worse. Are you not seeing a significantly degraded dev experience? The fact that users are modifying the example import maps to point to source rather than build to test files is evidence it's not just me.

More subjectively here's what the dev experience feels like in the dev branch right now:

1. Make a change to the "ExtrudeGeometry" file such as adding a console log.
2. Quickly switch to a browser with "webgl_geometry_text" open and refresh the page.
3. Refresh the page 10 to 20 times before the changes you made are available. During that time the page logs the error './three.core.js' does not provide an export named 'UniformsUtils' for a portion of the refreshes. The remaining refreshes all misleadingly load the example page as expected without the changes made.

Compare to r150:

1. Make a change to the "ExtrudeGeometry" file such as adding a console log.
2. Quickly switch to a browser with "webgl_geometry_text" open and refresh the page.
3. Refresh the page 1-4 times before the changes are available.

I've already made the mistake of thinking changes I made were present and wasted time testing something only to realize the I was looking at old code multiple times.

[Makio64]

M3 Pro Max :
build once

When I change for example PlaneGeometry :

I rarely use the examples from the lib directly to test my changes, but it's indeed feeling very slow and no hotreload as well.
I also had time to press f5 fews times before my change appear

[Mugen87]

Would using the existing npm run build-module as an alternative be a solution? Or is this script considered to be too slow as well?

[gkjohnson]

Would using the existing npm run build-module as an alternative be a solution? Or is this script considered to be too slow as well?

Using the "configOnlyModule" flag works better but still takes around 7-9 refreshes before the content is available and the './three.core.js' does not provide an export named 'UniformsUtils' error is still present.

Changing the config so only builds[ 1 ] is built changes the process such that it only takes 4 refreshes to see the changes. Not as good as r150 but a significant improvement. Using only builds[ 1 ] also removes the ./three.core.js error which to me indicates that these builds are all being done separately and files are being built multiple times if specified multiple times.

Is there a reason all the modules files are separated as separate build entries for rollup?