Issues from removal of source map content

[joshkel]

Bug description

#4520 removed source maps (specifically, sourcesContent) from the posthog-js package. This introduced two potential problems:

1. Our Webpack was set up to include our dependencies' source maps in our front-end bundle's own source maps, for the benefit of tools like Sentry. In practice, this may not matter much - PostHog is a reliable product, so it's unlikely to appear in a Sentry error report's captured stack trace. However, that PR's statement ("no, they don't reach anyone's bundle output. That's exactly why this is cheap to fix") seems incorrect or at least inadequate: they don't reach the executable bundle, but they can be included in the bundler's output (depending on bundler and configuration).
2. Webpack's source-map-loader complains when it's unable to resolve a source map entry. Since sourcesContent is now gone and the files referenced by posthog-js's sources don't exist, this now results in 125 warnings of console spam whenever we build our front-end bundle:

WARNING in ../../node_modules/posthog-js/dist/module.js
Module Warning (from ../../node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '/Users/josh/src/app/node_modules/posthog-js/src/utils/survey-event-receiver.ts' file: Error: ENOENT: no such file or directory, open '/Users/josh/src/app/node_modules/posthog-js/src/utils/survey-event-receiver.ts'

There'a also at least one absolute path from Posthog's build server that's being emitted:

WARNING in ../../node_modules/posthog-js/dist/module.js
Module Warning (from ../../node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '/Users/setup-pnpm/node_modules/.bin/store/v11/links/@/fflate/0.4.8/3d6bb6f51514b78f73eff8bf58c4fef7e18a9483e0eef595f39f3a49c6c31e1d/node_modules/fflate/esm/browser.js' file: Error: ENOENT: no such file or directory, open '/Users/setup-pnpm/node_modules/.bin/store/v11/links/@/fflate/0.4.8/3d6bb6f51514b78f73eff8bf58c4fef7e18a9483e0eef595f39f3a49c6c31e1d/node_modules/fflate/esm/browser.js'

How to reproduce

See https://github.com/joshkel/posthog-source-maps-missing for an LLM-generated test case.

Related sub-libraries

• All of them
• posthog-js (web)
• posthog-js-lite (web lite)
• posthog-node
• posthog-react-native
• @posthog/react
• @posthog/ai
• @posthog/convex
• @posthog/nextjs-config
• @posthog/nuxt
• @posthog/rollup-plugin
• @posthog/webpack-plugin

Additional context

If keeping source map debuggability is desired, then https://github.com/joshkel/posthog-source-maps-missing#suggestions contains some suggestions from the LLM on how to address the issue.

[github-actions]

AI triage for #4724

Conclusion: Confirmed compatibility regression for consumers whose Webpack configuration processes dependency source maps.
Confidence: 92%
Suggested labels: javascript, web, team/client-libraries

Thanks for the detailed reproduction. This is a valid downstream-bundler compatibility issue: the published maps retain sources but no longer contain sourcesContent, while the referenced TypeScript files are not shipped in the npm package. Webpack's source-map-loader therefore attempts to resolve those paths from node_modules and emits warnings; chained source maps also cannot retain PostHog source content.

The current behavior was introduced intentionally in #4520 to reduce the unpacked package size substantially, so the fix needs to choose a source-map publishing policy rather than simply suppressing a warning. We should evaluate a minimal approach that leaves every published map internally resolvable, including third-party paths such as fflate, and add a Webpack/source-map-loader regression test before changing packaging behavior.

Investigation

• packages/browser/package.json runs scripts/strip-sourcemap-sources-content.js during prepack, so every npm package removes sourcesContent from maps immediately before publishing.
• The stripping script deliberately preserves the .js.map files and their sources entries, but deletes sourcesContent in place. Its own comment states that downstream bundlers chain through the maps.
• The package's published files are limited to built outputs and selected subdirectories; src/ is not included. Consequently, source-map consumers that resolve a map's source paths from the installed package cannot find PostHog TypeScript source files.
• Rollup produces source maps for browser entrypoints (sourcemap: true), so this affects normal distributed browser bundles rather than an unused artifact.
• The current changelog records chore(browser): stop publishing dist source maps to npm #4520 as intentionally dropping npm sourcesContent, reducing the unpacked package from 40.8 MB to 17.4 MB. This confirms the report is a consequence of an active packaging decision, not a stale artifact.

Relevant files: packages/browser/package.json, packages/browser/scripts/strip-sourcemap-sources-content.js, packages/browser/src/__tests__/strip-sourcemap-sources-content.test.ts, packages/browser/rollup.config.mjs, packages/browser/CHANGELOG.md

Fix assessment

• Straightforward: no
• Risk: medium
• Reason: The immediate cause is clear, but no one-line change preserves both the package-size reduction and valid chained maps. Restoring all embedded contents increases package size; publishing/rebasing source paths must also account for bundled dependency sources and avoid exposing build-machine absolute paths. Disabling maps would avoid the resolution failures but regress source-map support.

Pi session

The resumable JSONL pi session for this run was saved to a private gist: https://gist.github.com/marandaneto/ec1076d4ac7a02792bf511f4d92149d1

Download it locally, then fork it into your own pi session:

pi --fork path/to/session.jsonl

Saved session:

• call-1-1-2026-09-01T14-06-12-752Z_01a05d4a-b710-7d5b-9cdd-6dd9d7d5fe54.jsonl

Close proposal

None. No issue close action was taken.

---

Generated by posthog-watcher-action using pi.

[marandaneto]

thanks @joshkel

@PostHog/team-error-tracking can you check this out?
see comment here #4520 (comment) @ablaszkiewicz

we cant fix or avoid warnings without restoring sourcesContent i think

[ablaszkiewicz]

@marandaneto

ad1 - I think it's ok. We did a lot to make sure that our package doesn't throw random errors and that everything is handled. We've had problems with it in the past and we even have an alert set for suspicious frames which look as if they came from within of our SDK

ad2 - Yeah I didn't know that. Managed to reproduce it on my machine. We gained a lot by excluding sources content so I think it was a good idea in general and I found a way to make webpack build with that configuration not emit warnings. We can stub sources content with a comment. I'm cooking a PR for that - wdyt?

[ablaszkiewicz]

Also haven't found any other case which would emit warnings or have some problems with that. Fact is that if our SDK throws, any debugger will just show this stubbed content - I think it's still worth doing because this saved ~50% of package size

[marandaneto]

@marandaneto

ad1 - I think it's ok. We did a lot to make sure that our package doesn't throw random errors and that everything is handled. We've had problems with it in the past and we even have an alert set for suspicious frames which look as if they came from within of our SDK

ad2 - Yeah I didn't know that. Managed to reproduce it on my machine. We gained a lot by excluding sources content so I think it was a good idea in general and I found a way to make webpack build with that configuration not emit warnings. We can stub sources content with a comment. I'm cooking a PR for that - wdyt?

agree, lets do this

[salvoravida]

Same root cause, different bundler — adding the Vite case, since the failure mode looks different enough that it may not obviously match this issue.

Setup: Vite 8 dev server, React Router framework mode, posthog-js in ssr.noExternal (which PostHog's React Router guide asks for — without it the server build fails). That makes Vite SSR-transform the package, which makes it chain through dist/module.mjs.map.

What you get on posthog-js@1.433.5:

Sourcemap for ".../node_modules/posthog-js/dist/module.mjs" points to a source file
outside its package: ".../node_modules/browser-common/dist/utils/globals.mjs"

Sourcemap for ".../node_modules/posthog-js/dist/module.mjs" points to a source file
outside its package: ".../node_modules/core/dist/types.mjs"
...

Not ENOENT like webpack's source-map-loader: Vite's injectSourcesContent has a path-traversal guard that bails before touching the filesystem whenever a resolved source sits outside the package root, and emits warnOnce per distinct path.

One detail that I don't think is in the issue yet: the workspace sources lose their npm scope. dist/module.mjs.map contains entries like

../../browser-common/dist/utils/globals.mjs     (23 entries)
../../core/dist/types.mjs                       (45 entries)

Relative to posthog-js/dist/, those resolve to node_modules/browser-common and node_modules/core, which don't exist — the published packages are @posthog/browser-common and @posthog/core, so the paths would have to be ../../@posthog/core/.... They read as siblings from the monorepo layout (packages/core, packages/browser-common) rather than as published specifiers. Under pnpm they land outside the package root either way, which is what trips the Vite guard.

Totals for module.mjs.map on 1.433.5: 133 sources, no sourcesContent, 69 of those sources outside the package — 45 core, 23 browser-common, plus the one setup-pnpm/.../fflate CI path already quoted above.

The stubbed-sourcesContent fix discussed in this thread would cover this case too: with content present Vite never goes to disk, the guard never fires, and the missing scope stops mattering for this particular warning.