feat(browser): Tree shaking - extract extension constructors from core bundle#3080
Merged
dustinbyrne merged 7 commits intomainfrom Feb 25, 2026
Merged
feat(browser): Tree shaking - extract extension constructors from core bundle#3080dustinbyrne merged 7 commits intomainfrom
dustinbyrne merged 7 commits intomainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Contributor
|
Size Change: +8.41 kB (+0.13%) Total Size: 6.44 MB
ℹ️ View Unchanged
|
This is a starting point for permitting the bundle to be tree shaken. this change should effectively be a no-op, with the default extensions replacing the entirety of what was previously available.
No prepackaged extensions. This bundle is not currently exported. It's useful in its current state in showing what the maximum byte size return is when tree shaking.
dustinbyrne
force-pushed
the
feat/web-tree-shakable
branch
from
b1f2266 to
eeac1f7
Compare
Why not
dustinbyrne
force-pushed
the
feat/web-tree-shakable
branch
from
76e3dc7 to
3669a5b
Compare
Member
|
step by step and 18.4% is already a big step, nice |
marandaneto
approved these changes
Feb 21, 2026
Member
|
this is exciting... that array.js doesn't go down is a good indication it's not breaking. what's most helpful from review @dustinbyrne i can check it out locally and do some testing? |
Contributor
Author
|
I've also done a fair amount of local testing myself and everything looks good. If nothing immediately jumps out at you I feel like that's a pretty strong signal. I think this is fairly low risk. |
pauldambra
approved these changes
Feb 24, 2026
Member
pauldambra
left a comment
pauldambra
left a comment
There was a problem hiding this comment.
this looks really great. love we can do this without a breaking change needed
|
Hey @dustinbyrne, this PR seemingly completely broke my SvelteKit site on Vercel with the following very obscure stack trace: It works for me locally, only breaks when deployed to Vercel I also get those logs on Vercel before the 500: |
Contributor
Author
|
Hey @WarningImHack3r, thanks for reaching out. I've decided to drop the explicit exports and return to the previous method of package resolution. If you update to v1.356.2 or later, module resolution will once again behave as it did before this change. |
|
@dustinbyrne thank you very much! Can confirm it's working now :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The posthog-js browser bundle ships all extension code (autocapture, session recording, heatmaps, dead clicks, web vitals, tracing headers, etc.) to every user, even those who only need core event capture and
feature flags. There's no way to opt out of this code at the bundle level.
Changes
Makes extension classes injectable rather than hardcoded in
posthog-core.ts, enabling tree-shakeable bundles.Architecture change:
posthog-core.tstoimport type(type-only), removing them from the runtime bundlePostHog.__defaultExtensionClassesstatic property for side-effect registrationsrc/entrypoints/default-extensions.tswhich is a side-effect module that pre-registers all extension classes_initExtensions()merges__defaultExtensionClasseswithconfig.__extensionClasses, skipping extensions that aren't registeredNew exports:
posthog-js/slim— An experimental slim entrypoint that excludes all default extensions. Users opt in to specific extensions viaconfig.__extensionClasses.posthog-js/extensionscontains pre-grouped extension bundles (ReplayExtensions,AnalyticsExtensions,ErrorTrackingExtensions,ProductToursExtensions,SiteAppsExtensions,TracingExtensions,AllExtensions) for use with the slim entrypoint. This is mostly DX, as it groups extensions with their dependencies.Usage:
All existing entrypoints import
./default-extensionsso behavior is identical, without breaking changes. The new/slimand/extensionsexports are additive.Current bundle size impact:
module.js(current)module.slim.js(new)[Taking this further[(https://github.com//pull/3097) I was able to get the bundle down to 31.4 KB gzipped (a savings of 24.4 KB, or a 43.72% reduction), so there's more room for improvement here, but I've intentionally tried to keep this initial change on the smaller side.
Release info Sub-libraries affected
Libraries affected
Checklist
If releasing new changes
pnpm changesetto generate a changeset file