@openpanel/web emits the replay chunk (rrweb, ~55 KB gz) even for apps that never set sessionReplay.enabled. #336 made it lazy, so no TTI cost, but loadReplayModule still does an unconditional import('./replay'), so the bundler always emits it and deploys it as dead code. Consumers can only drop it by stubbing rrweb or patching the package. (context: #336 (comment))
Proposal: opt-in replay subpath
Base package stops importing ./replay; expose the recorder as @openpanel/web/replay and let consumers pass it in:
import { OpenPanel } from '@openpanel/web'
import { startReplayRecorder } from '@openpanel/web/replay'
new OpenPanel({ sessionReplay: { enabled: true, recorder: startReplayRecorder } })rrweb then only enters a bundle when the subpath is imported. Replay users add one import, everyone else gets a lean build for free. The IIFE build already stubs replay via an esbuild plugin, so this mostly surfaces existing decoupling at the API level.
Smaller alternative if the API change is too much: a replay-free library entry or a build flag.
Follows up on #336.
@openpanel/webemits the replay chunk (rrweb, ~55 KB gz) even for apps that never setsessionReplay.enabled. #336 made it lazy, so no TTI cost, butloadReplayModulestill does an unconditionalimport('./replay'), so the bundler always emits it and deploys it as dead code. Consumers can only drop it by stubbing rrweb or patching the package. (context: #336 (comment))Proposal: opt-in replay subpath
Base package stops importing
./replay; expose the recorder as@openpanel/web/replayand let consumers pass it in:rrweb then only enters a bundle when the subpath is imported. Replay users add one import, everyone else gets a lean build for free. The IIFE build already stubs replay via an esbuild plugin, so this mostly surfaces existing decoupling at the API level.
Smaller alternative if the API change is too much: a replay-free library entry or a build flag.
Follows up on #336.