feat(server-utils): initial module scaffolding#21200
Open
isaacs wants to merge 1 commit into
Open
Conversation
Member
Author
|
Actually it looks like this might not be possible without a breaking change, because the cycles will end up confounding TSC when it builds our code, as core and server-utils would depend on one another for types. The only option would be to shim everything, which gets pretty gross. |
Member
Couldn't we just prepare to move them in a separate folder right now and in v11 we just move the folder into its own package? |
Member
Author
Right, so that would kind of be the combination of the (3) and (1) options I discussed in #21222. (That is, put everything in But, there's not much hazard in creating the server-utils package now, but not removing anything from core (only putting stuff in server-utils in v10 that is net new), and migrating exisitng |
isaacs
added a commit
that referenced
this pull request
May 29, 2026
This is phase 1 of the plan to move all server utils into a single reusable package that can be shared across SSJS SDKs. Right now it does not do much, just houses the `diagnostics_channel` redis integrations. In subsequent steps: 1. Code will *not* be moved out of `@sentry/core/server` into `@sentry-internal/server-utils`, in v10. 2. Some or all code in `@sentry/core/server` may be moved into `@sentry-internal/server-utils` in v11, as this would be breaking change. (Redis channel integration was not, because it hasn't yet shipped in a release. Other high-level portable components may move over later, if justified.) 3. No components will ever live in *both* places, because `server-utils` depends on `core`, and that would create a type dependency cycle. `@sentry/core/server` will live on for at least v10, possibly into v11. New server components will be placed in `@sentry-internal/server-utils`.
isaacs
force-pushed
the
isaacs/sentry-internal-server-utils
branch
from
4aee846 to
67a409f
Compare
isaacs
changed the title
isaacs
changed the title
isaacs
added a commit
that referenced
this pull request
May 29, 2026
This is phase 1 of the plan to move all server utils into a single reusable package that can be shared across SSJS SDKs. Right now it does not do much, just houses the `diagnostics_channel` redis integrations. In subsequent steps: 1. Code will *not* be moved out of `@sentry/core/server` into `@sentry-internal/server-utils`, in v10. 2. Some or all code in `@sentry/core/server` may be moved into `@sentry-internal/server-utils` in v11, as this would be breaking change. (Redis channel integration was not, because it hasn't yet shipped in a release. Other high-level portable components may move over later, if justified.) 3. No components will ever live in *both* places, because `server-utils` depends on `core`, and that would create a type dependency cycle. `@sentry/core/server` will live on for at least v10, possibly into v11. New server components will be placed in `@sentry-internal/server-utils`. fix: #21222 fix: JS-2631
isaacs
force-pushed
the
isaacs/sentry-internal-server-utils
branch
from
67a409f to
b332298
Compare
Contributor
size-limit report 📦
|
This is phase 1 of the plan to move all server utils into a single reusable package that can be shared across SSJS SDKs. Right now it does not do much, just houses the `diagnostics_channel` redis integrations. In subsequent steps: 1. Code will *not* be moved out of `@sentry/core/server` into `@sentry-internal/server-utils`, in v10. 2. Some or all code in `@sentry/core/server` may be moved into `@sentry-internal/server-utils` in v11, as this would be breaking change. (Redis channel integration was not, because it hasn't yet shipped in a release. Other high-level portable components may move over later, if justified.) 3. No components will ever live in *both* places, because `server-utils` depends on `core`, and that would create a type dependency cycle. `@sentry/core/server` will live on for at least v10, possibly into v11. New server components will be placed in `@sentry-internal/server-utils`. fix: #21222 fix: JS-2631
isaacs
force-pushed
the
isaacs/sentry-internal-server-utils
branch
from
1e2b91f to
39f2781
Compare
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
2 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.
This is phase 1 of the plan to move all server utils into a single reusable package that can be shared across SSJS SDKs.
Right now it does not do much, just houses the
diagnostics_channelredis integrations. In subsequent steps:@sentry/core/serverinto@sentry-internal/server-utils, in v10.@sentry/core/servermay be moved into@sentry-internal/server-utilsin v11, as this would be breaking change. (Redis channel integration was not, because it hasn't yet shipped in a release. Other high-level portable components may move over later, if justified.)server-utilsdepends oncore, and that would create a type dependency cycle.@sentry/core/serverwill live on for at least v10, possibly into v11. New server components will be placed in@sentry-internal/server-utils.fix: #21222
fix: JS-2631