Earcut: Bundle earcut from source rather than copying code

[gkjohnson]

Related issue: #30698 (comment)

Description

Removes the copied earcut code and adds earcut as a dev dependency. The earcut code is still bundled into the final three.js distribution files so "three" still has no dependencies. This makes it easier to update the earcut algorithm from upstream.

If needed we can "fix" the earcut version so it doesn't automatically update on patch or minor changes.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	336.02 78.26	336.02 78.26	+0 B +0 B
WebGPU	524.99 146.23	524.99 146.23	+0 B +0 B
WebGPU Nodes	524.46 146.12	524.46 146.12	+0 B +0 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	465.06 112.14	465.06 112.14	+0 B +0 B
WebGPU	597.77 162.49	597.77 162.49	+0 B +0 B
WebGPU Nodes	552.89 151.97	552.89 151.97	+0 B +0 B

[gkjohnson]

Has something changed with the E2E CI tests? I'm getting errors in a number of examples where the randomness values are completely different:

css3d sandbox

expected	actual

[Mugen87]

Nothing has changed in the CI setup lately. Unfortunately, a rerun of the CI does not solve the issue.

I've tested the PR locally and there seems to be a build issue. The are some new files with strange names (TextureUtils-*) generated in the build directory:

[gkjohnson]

The are some new files with strange names (TextureUtils-*) generated in the build directory:

Oh interesting I missed those - thanks. It's still odd to me that this affected the CI but I don't fully understand how the e2e tests function 😅. I fixed the issue in the latest commit by limiting the limiting the node resolve plugin to just external libraries.

[Mugen87]

Let's give this a try!

[sunag]

I don't know if it's a good idea to have external dependencies in the core, could we move Earcut and ShapeUtils class to addons? If we try to import three.js through ./src/three.webgpu.js instead of ./build/three.webgpu.js, this functionality is lost. But what worries me is the break in standards.

[Mugen87]

could we move Earcut and ShapeUtils class to addons?

We need triangulation for shape and extrude geometry so a bunch of things would have to be moved out of core. I would like to avoid so many breaking changes, tbh.

If we try to import three.js through ./src/three.webgpu.js

Do we need to support this use case?

[sunag]

I hadn't noticed the dependencies, we really have a lot here.

About ./src/three.webgpu.js it was used for PR example demos without having to create builds in a new PR, I also use it in development to gain a few seconds in previews by avoiding compilation time, nothing that can't be worked around, just a lost convenience.

[Mugen87]

Given the improvements in maintainability, loosing ./src/three.webgpu.js as an inofficial entry point sounds acceptable to me. I understand the convenience aspect but the more standard the workflows are, the better. Every import of core modules should target files the build directory.

[gkjohnson]

It occurs to me that some users may still be using src/Three.js for treeshaking, as well 🤦 We can try publishing and see if people complain. Or we can include "earcut" as an optional dependency (or these power users will have to install it themselves). Or we can copy the mapbox/earcut file without changes to the project so we retain the ability to easily update the file without these kinds of uses breaking.

[Mugen87]

Or we can copy the mapbox/earcut file without changes to the project so we retain the ability to easily update the file without these kinds of uses breaking

Then I vote for this option. But we have to make sure ESLint and stuff like DeepScan ignore the file. Maybe we can place the code in src/libs and then exclude the directory from linting and code scanning.