Currently, a bunch of pieces of core are in @sentry/core/server, separated out from @sentry/core/browser for more reliable tree shaking.
It would be good (to get benefits of different TS configs, project testing, etc.) to actually make this a whole standalone package, similar to @sentry-internal/browser-utils, to contain integrations and utilities that all SSJS platforms need, but which threaten to blow up the size of core. Then, @sentry/core can be strictly isomorphic lower-level utilities.
Note for discussion: originally we had discussed doing this in a backwards compatible way, however this can easily introduce a problematic dependency cycle, which thwarts TSC's ability to build our code. (Eg, core has to depend on server-utils to continue to export what it's currently exporting in the ./server submodule export, but that thing in server-utils depends on core for its underlying functionality.)
We have three options, each with some trade-offs:
- Put this off until v11, and do it as a breaking change. No more server components in core. That's not super far away, though it does feel a bit arbitrary, and it can limit the up-take, since we're imposing a breaking change. That said,
core is semi-internal, so as long as the exported interfaces in the platform SDKs don't change, it's not likely to prevent anyone from upgrading.
- Limit what we put in
server-utils to strictly things that are net-new additions, or moved out of node-core for use in other platforms, and re-export whatever is in @sentry/core/server. This somewhat limits the value that the change can provide, but we continue to maintain @sentry/core/server for now (perhaps even indefinitely). But, there is some justification here: @sentry/core/server is core reusable utilities for all server SDKs. @sentry-internal/server-utils is higher-level integrations and features.
- Ditch this idea, just lean into
@sentry/core/server. This isn't my favorite idea, because there are nice benefits to greater isolation. But, it does avoid the dependency cycles, and provides most of the benefit of greater tree-shaking reliability, if not the disk-space install size benefits for browser SDK users.
For now, unless someone makes the case to do a different approach, I'll continue with option (2).
Currently, a bunch of pieces of core are in
@sentry/core/server, separated out from@sentry/core/browserfor more reliable tree shaking.It would be good (to get benefits of different TS configs, project testing, etc.) to actually make this a whole standalone package, similar to
@sentry-internal/browser-utils, to contain integrations and utilities that all SSJS platforms need, but which threaten to blow up the size of core. Then,@sentry/corecan be strictly isomorphic lower-level utilities.Note for discussion: originally we had discussed doing this in a backwards compatible way, however this can easily introduce a problematic dependency cycle, which thwarts TSC's ability to build our code. (Eg, core has to depend on server-utils to continue to export what it's currently exporting in the
./serversubmodule export, but that thing in server-utils depends on core for its underlying functionality.)We have three options, each with some trade-offs:
coreis semi-internal, so as long as the exported interfaces in the platform SDKs don't change, it's not likely to prevent anyone from upgrading.server-utilsto strictly things that are net-new additions, or moved out ofnode-corefor use in other platforms, and re-export whatever is in@sentry/core/server. This somewhat limits the value that the change can provide, but we continue to maintain@sentry/core/serverfor now (perhaps even indefinitely). But, there is some justification here:@sentry/core/serveris core reusable utilities for all server SDKs.@sentry-internal/server-utilsis higher-level integrations and features.@sentry/core/server. This isn't my favorite idea, because there are nice benefits to greater isolation. But, it does avoid the dependency cycles, and provides most of the benefit of greater tree-shaking reliability, if not the disk-space install size benefits for browser SDK users.For now, unless someone makes the case to do a different approach, I'll continue with option (2).