@sparkjsdev/spark@2.0.0 is difficult to tree-shake when importing only SplatMesh

[fabiopolimeni]

The following report has been generated by an AI agent, but the issue I am facing is real. Maybe there is a workaround, but it would be nicer if the spark module wouldn't take 5MB.

We upgraded from @sparkjsdev/spark@0.1.10 to @sparkjsdev/spark@2.0.0 and saw a large increase in our main web bundle, even though our app only imports SplatMesh from the root package.

What we observed

• Our main chunk increased from about 4,769.49 kB to 9,229.18 kB after the upgrade.
• The increase is almost entirely explained by the Spark package itself.

How we import Spark

We only import SplatMesh from the package root:

import { SplatMesh } from "@sparkjsdev/spark";

Package inspection

After inspecting the published package for 2.0.0, we found:

• The package resolves browser imports to a single root ESM file: dist/spark.module.js.
• dist/spark.module.js is about 5.1 MB unminified.
• The package has no subpath exports for narrower imports.
• The package has no sideEffects field in package.json.
• The root ESM bundle contains multiple large runtime features together, including:
  • embedded base64 WASM payloads
  • worker bootstrap code
  • broad exports from one root entry, including SparkRenderer, OldSparkRenderer, SparkXr, SparkControls, SparkPortals, loaders, edit systems, and splat containers
• SplatMesh appears to trigger eager static initialization from the root module, which seems to pull WASM/runtime setup into the main bundle.

Why this seems problematic

From a consumer point of view, importing only SplatMesh from the package root appears to retain a much larger part of the library than expected. That makes it hard for bundlers to keep the entry chunk small.

Questions

• Could Spark expose smaller subpath exports for major surfaces like SplatMesh?
• Could the root package avoid eager static initialization at module load time?
• Could the WASM and worker runtime be split out so that importing SplatMesh does not immediately retain so much code in the main bundle?

[mrxz]

The size increase from 0.1.10 to 2.0.0 is something that can and should be improved (opened #321). Generally applications using Spark will end up loading large amounts of splat data, making the size of Spark not the dominant factor. That said, there's currently a lot of (optional) bloat that could be shaved off.

We only import SplatMesh from the package root:
Worth noting that with 2.0.0 it's expected that you create a SparkRenderer as well. In 0.1.10 this was done automatically, but that's no longer the case. Regardless, importing just SplatMesh and SparkRenderer should not have to result in the entire library being included.

That said, there are several monolithic classes in Spark where most features come together. So even with minimal usage, you'd likely end up depending on the majority of this code. Initial support for tree-shaking is likely going to be somewhat coarse.