Source build version from shared metadata.version#326
Open
Conversation
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
5 tasks
watson
force-pushed
the
watson/DEBUG-5465/inject-version-at-runtime
branch
from
eb80c25 to
a800ced
Compare
tylfin
approved these changes
Apr 27, 2026
Expose the configured `liveDebugger.version` in the injected runtime bootstrap so the Browser Debugger SDK can default its runtime version from build metadata. Move the bootstrap logic into a dedicated helper and document the new behavior.
The deployed build identifier is a cross-plugin concern rather than a Live Debugger one. Move it from `liveDebugger.version` onto the shared `metadata.version` field, alongside the existing `metadata.name`. Type-validation of the shared `metadata` block is centralized in the factory's `validateOptions`, so consumers don't each re-implement it. Only `metadata.version` is validated today: a TODO in factory/validate.ts flags that `metadata.name` should also be tightened in the next major, since the root README has long documented its default as `null`, and adding the check now would break users who took that literally. The Live-Debugger-specific invariant — `metadata.version` must match `errorTracking.sourcemaps.releaseVersion` when both are configured — stays in the live-debugger validator, since that's the plugin enforcing it.
watson
force-pushed
the
watson/DEBUG-5465/inject-version-at-runtime
branch
from
a800ced to
eeba682
Compare
watson
changed the title
Have `errorTracking.sourcemaps.releaseVersion` and `rum.sourceCodeContext.version` fall back to the shared `metadata.version` when no plugin-specific value is configured. Users who declare the build version once at the top level no longer need to repeat it under each plugin namespace. To support the fallback, `SourcemapsOptions.releaseVersion` is loosened from required to optional. The existing "is required" check still fires when neither `sourcemaps.releaseVersion` nor `metadata.version` resolves, with an updated message that mentions both options. Document `metadata.version` as a top-level option in the root README so it sits alongside `metadata.name`, and update the auto-generated configuration block template in `@dd/tools` accordingly.
watson
changed the title
yoannmoinet
reviewed
Apr 29, 2026
Member
yoannmoinet
left a comment
yoannmoinet
left a comment
There was a problem hiding this comment.
I'm not sure I understand why the errorTracking concern is handled by the liveDebugger plugin.
I don't think these two plugins should know anything about each others.
| ``` | ||
|
|
||
| Optional. When set, use an immutable deployed browser build identifier. This value should match: | ||
| If both `metadata.version` and an explicit `errorTracking.sourcemaps.releaseVersion` are configured and disagree, this plugin surfaces the mismatch as a build error. |
Member
There was a problem hiding this comment.
Not sure this is super relevant for the Live Debugger plugin's documentation.
Comment on lines
+26
to
+28
| if (metadataVersion && sourcemapReleaseVersion && metadataVersion !== sourcemapReleaseVersion) { | ||
| errors.push( | ||
| `${red('version')} must match ${red('errorTracking.sourcemaps.releaseVersion')} when both Live Debugger and sourcemap upload are configured`, | ||
| `${red('metadata.version')} must match ${red('errorTracking.sourcemaps.releaseVersion')} when both Live Debugger and sourcemap upload are configured`, |
Member
There was a problem hiding this comment.
Does it make sense to have this validation in the live debugger plugin?
I would probably see this more in the error tracking plugin instead.
Comment on lines
+20
to
+21
| const makeConfig = (liveDebugger?: unknown, errorTracking?: unknown, metadata?: unknown): Options => | ||
| ({ liveDebugger, errorTracking, metadata }) as unknown as Options; |
Member
There was a problem hiding this comment.
Nit: not a fan of all these unknown casting.
All the types are accessible and we have a bunch of mocks to alleviate the burden of mocking these out.
Comment on lines
+106
to
+109
| // Build the resolved config only when `releaseVersion` actually | ||
| // resolves; otherwise an error has been recorded and the caller will | ||
| // throw before the config is read. | ||
| if (releaseVersion) { |
Member
There was a problem hiding this comment.
Not sure this if () {} wrapping is really necessary.
It brings more confusion when reading the code than anything.
Even the comment tends to explain that it's actually unnecessary since it would throw anyways.
|
|
||
| export type LiveDebuggerOptions = { | ||
| enable?: boolean; | ||
| version?: string; |
Member
There was a problem hiding this comment.
I believe it's acceptable to remove it from the public API since the plugin didn't actually release publicly yet, but just to confirm it's not been missed.
This was referenced Apr 30, 2026
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
3 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.
What and why?
This PR makes
metadata.versionthe canonical place to declare the deployed build identifier across the Datadog build plugins. Three plugins now read from it:versionduringinit()— keeping browser build lookup and source-code resolution working without extra SDK wiring.errorTracking.sourcemaps.releaseVersion) falls back to it when no plugin-specific value is set.rum.sourceCodeContext.version) falls back to it when no plugin-specific value is set.Users who declare the build version once at the top level no longer need to repeat it under each plugin namespace. The change is additive: existing per-plugin configurations keep working unchanged.
This builds on #325, which introduced build-time validation of the version but stopped short of using it at runtime.
How?
BuildMetadata(in@dd/core/types) gains an optionalversion?: string, alongside the existingname. The root README documents it as a top-level option, and the auto-generated configuration block template in@dd/toolsis updated to include it.metadata.*is centralized in the factory'svalidateOptions. Today it strictly type-checksmetadata.version. A TODO flagsmetadata.nameto be tightened in the next major — its documented default is currentlynull, so adding the check now would be a breaking change.metadata.versionmust matcherrorTracking.sourcemaps.releaseVersionwhen both are explicitly configured.runtime-bootstraphelper. The bootstrap installs the minimal$dd_probesno-op stub, and whenmetadata.versionis set it also exposes build metadata on a runtime-visible global so the Browser Debugger SDK can default itsversionfrom there duringinit().SourcemapsOptions.releaseVersionis loosened from required to optional. The existing "is required" check still fires when neithersourcemaps.releaseVersionnormetadata.versionresolves, with an updated message that mentions both options.