You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In spite of the fact that - theoretically - updating one of our top-level packages (@sentry/browser, @sentry/node, and all framework-specific packages) should also update all monorepo dependencies (@sentry/utils, @sentry/core, etc), it's come up as a problem multiple times that this doesn't always happen. As a result, people end up with crashes when, for example, a newer version of @sentry/browser calls upon a recently-added hub method, an older version of @sentry/hub is still installed, and the user ends up with a undefined is not callable error.
This never comes up as a problem for people using our CDN bundle, because in that case all monorepo dependencies are included in the bundle.
Solution Brainstorm
To solve this, let's include our monorepo dependencies in our npm packages the same way we do in our bundles. We can still publish the dependencies as separate packages, for anyone who specifically needs them (people building community SDKs for frameworks we don't support, for example), but we'd stop listing them as runtime dependencies.
UPDATE: This is going to be trickier than I thought.
Leaving a note here for myself, of things I've tried which have not yet worked, for when I come back to this:
(tried with building nextjs SDK and bundling either utils or react packages)
move package to dev deps, don’t mark dev deps as external (adjust output for templates, loaders, adjust script to copy file to correct location)-> build/esm and build/cjs contain nextjs dir, dir for each non-external package, but doesn't work because other packages only contain esm, not cjs
symlink src folder from other package as nextjs/src/packages/ and change imports to point to that -> files from other package don't get included in build
symlink src/index.ts from other package into nextjs/src/packages/ and change imports to point to `./packages/ -> complains it can't find the module (not reading through symlink)
copy contents of other package src folder into nextjs/src/packages/ -> need to add all of other package's deps to nextjs package deps, turn on flags from other package builds (like jsx for react package)
copy correct files into build/esm and build/cjs folders, use output.paths rollup option to rewrite import to point to that folder -> replacement is hardcoded, so doesn't account for differences in relative path
Alternative option: Crate post-install script to verify versions of all deps, warn or error if out of sync (Not perfect - some people turn off scripts - but a lot better than nothing)
The text was updated successfully, but these errors were encountered:
Problem Statement
In spite of the fact that - theoretically - updating one of our top-level packages (
@sentry/browser
,@sentry/node
, and all framework-specific packages) should also update all monorepo dependencies (@sentry/utils
,@sentry/core
, etc), it's come up as a problem multiple times that this doesn't always happen. As a result, people end up with crashes when, for example, a newer version of@sentry/browser
calls upon a recently-added hub method, an older version of@sentry/hub
is still installed, and the user ends up with aundefined is not callable
error.This never comes up as a problem for people using our CDN bundle, because in that case all monorepo dependencies are included in the bundle.
Solution Brainstorm
To solve this, let's include our monorepo dependencies in our npm packages the same way we do in our bundles. We can still publish the dependencies as separate packages, for anyone who specifically needs them (people building community SDKs for frameworks we don't support, for example), but we'd stop listing them as runtime dependencies.
UPDATE: This is going to be trickier than I thought.
Leaving a note here for myself, of things I've tried which have not yet worked, for when I come back to this:
(tried with building nextjs SDK and bundling either utils or react packages)
output.paths
rollup option to rewrite import to point to that folder -> replacement is hardcoded, so doesn't account for differences in relative pathAlternative option: Crate post-install script to verify versions of all deps, warn or error if out of sync (Not perfect - some people turn off scripts - but a lot better than nothing)
The text was updated successfully, but these errors were encountered: