The TSL / WebGPU cone, gathered behind ONE module.
This is the only module under src/ that may statically import
three/webgpu or three/tsl (transitively, via the *-tsl / *.tsl
modules it pulls in). Everything else reaches these classes and factories
through rendering/tsl/load, which imports this file
dynamically — so rolldown places this whole subgraph, plus the ~182 kB
gzipped three-webgpu chunk, in a lazy chunk that is fetched only when the
WebGPU backend is actually selected.
That is the entire point of the file's existence, and the reason it looks
like a barrel with nothing of its own to say. Two gates hold it: the ESLint
no-restricted-imports rule in eslint.config.js, which bans value imports
of three/webgpu / three/tsl outside this file and the *-tsl modules it
owns, and scripts/check-eager-chunks.mjs, which asserts against the built
dist/ that nothing eagerly reachable from the entry imports the chunk.
Both are needed: the previous arrangement — 23 production modules importing
three/webgpu directly — cost every WebGL user a download they never
executed, and the last edge was not in the source at all but in how the
shared three.core.js was chunked. Nothing in the repo noticed for as long
as either was true. See issue #1679.
Two things do NOT belong here:
Type-only imports of these symbols. import type { PointTSLMaterial } is
erased at build time and costs nothing, so consumers should keep doing
that directly rather than routing types through the registry.
Anything that the WebGL path needs. If a symbol turns out to be required
before the backend is known, it does not belong in the lazy cone at all —
move it to a module with no three/webgpu edge (the precedent is
material-manager/soft-dispose-flag.ts, a zero-import leaf that exists
for exactly this reason).
The TSL / WebGPU cone, gathered behind ONE module.
This is the only module under
src/that may statically importthree/webgpuorthree/tsl(transitively, via the*-tsl/*.tslmodules it pulls in). Everything else reaches these classes and factories throughrendering/tsl/load, which imports this file dynamically — so rolldown places this whole subgraph, plus the ~182 kB gzippedthree-webgpuchunk, in a lazy chunk that is fetched only when the WebGPU backend is actually selected.That is the entire point of the file's existence, and the reason it looks like a barrel with nothing of its own to say. Two gates hold it: the ESLint
no-restricted-importsrule ineslint.config.js, which bans value imports ofthree/webgpu/three/tsloutside this file and the*-tslmodules it owns, andscripts/check-eager-chunks.mjs, which asserts against the builtdist/that nothing eagerly reachable from the entry imports the chunk. Both are needed: the previous arrangement — 23 production modules importingthree/webgpudirectly — cost every WebGL user a download they never executed, and the last edge was not in the source at all but in how the sharedthree.core.jswas chunked. Nothing in the repo noticed for as long as either was true. See issue #1679.Two things do NOT belong here:
import type { PointTSLMaterial }is erased at build time and costs nothing, so consumers should keep doing that directly rather than routing types through the registry.three/webgpuedge (the precedent ismaterial-manager/soft-dispose-flag.ts, a zero-import leaf that exists for exactly this reason).