feat(js): Add _BASE attribute key exports for dynamic attribute keys

[Lms24]

Description

Currently, the JS conventions package exports attribute key constants with a dynamic suffix like so:

export const URL_PATH_PARAMETER_KEY = 'url.path.parameter.<key>';

This makes it a bit annoying to use this export in SDKs when setting such attributes because you have to write code like

span.setAttribute(URL_PATH_PARAMETER_KEY.replace('<key>', actualKey), actualValue);

this PR adds an additional export with a _BASE suffix, so that we export

export const URL_PATH_PARAMETER_KEY = 'url.path.parameter.<key>';
export const URL_PATH_PARAMETER_KEY_BASE = 'url.path.parameter';

which means we can more ergonomocally write

span.setAttribute(`${URL_PATH_PARAMETER_KEY_BASE}.${actualKey}`, actualValue);

while this doesn't look much shorter, bundlers and minifiers can much more efficiently minify this to something like

s.setAttribute(`${x}.{y}`,z);

// as opposed to

s.setAttribute(x.replace(u,y),z);

plus, we also save a tiny bit of perf overhead by avoiding the replace call.

Alternatives Considered

The package or the respective SDK could expose a dynamicAttributeKey(attributeKey, suffix): string helper which would take care of replacing.

span.setAttribute(dynamicAttributeKey(URL_PATH_PARAMETER_KEY, actualKey), actualValue)

// minifies roughly to
s.setAttribute(d(u,y),z) // + bytes for the helper

This avoids the export but we'd still call .replace on every attribute creation site. Bundle-size wise, it would most likely also be larger than be equal to using the constants and string templates (depending a bit on number of attributes).

Both approaches fix one issue that's most important to me: We can ergonomically directly reference the attribute constants in code, and thereby get deprecation warnings when linting.

Happy to make the same modification to python code generation if desired.

PR Checklist

• I have run yarn test and verified that the tests pass.
• I have run yarn generate to generate and format code and docs.

If an attribute was added:

• The attribute is in a namespace (e.g. nextjs.function_id, not function_id)
• I have used the correct value for apply_scrubbing (i.e. manual or auto. Use never only for values that should never be scrubbed such as IDs)

If an attribute was deprecated:

• I've followed the policies described in CONTRIBUTING.md

[github-actions]

Semver Impact of This PR

🟡 Minor (new features)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

New Features ✨

Attributes

• Add sentry.metric.source by klochek in #476
• Add faas.id (deprecated) in favor of cloud.resource_id by andreiborza in #475
• Add faas.execution (deprecated) in favor of faas.invocation_id by andreiborza in #473
• Add messaging attributes by s1gr1d in #469
• Add url.same_origin (deprecated) and http.request.same_origin (replacement) attributes by Lms24 in #456
• Add db.response.status_code by s1gr1d in #462

Other

• (ai) Add granular cost attributes for cache and reasoning by vgrozdanic in #461

• (js) Add _BASE attribute key exports for dynamic attribute keys by Lms24 in #471

Internal Changes 🔧

• (ci) Stop inheriting secrets for changelog-preview by tobias-wilfert in #463

---

_{🤖 This preview updates automatically when you update the PR.}

[mydea]

makes sense to me!

[mjq]

👍 An alternative would be shipping a function that does the concatenation for you (maybe slightly more foolproof - no chance of missing the dot separator?) but this seems fine and is an improvement for sure.

[Lms24]

shipping a function that does the concatenation for you

Would it be helpful for how we use it in the sentry repo? If so, happy to add that as a follow up,
I think for the JS SDK, I'd slightly prefer the direct string templates for now to avoid the .replace calls.

[nsdeschenes]

shipping a function that does the concatenation for you

Would it be helpful for how we use it in the sentry repo? If so, happy to add that as a follow up, I think for the JS SDK, I'd slightly prefer the direct string templates for now to avoid the .replace calls.

Rather than .replace i think @mjq was suggesting something like:

// conventions package
export const dynamicAttributeKey = (baseKey: <union literal of base keys>, dynamicKey: string) => `${baseKey}.${dynamicKey}`

// sdk/ui/etc.
span.setAttribute(dynamicAttributeKey(URL_PATH_PARAMETER_KEY_BASE, actualKey), actualValue)

You could also probably do some funky type stuff around the base key to only allow base keys to be entered etc.

[Lms24]

ah yeah, brain fart form my end, sorry 🤦 I guess that still involves an extra function call but you're right, it adds some more safety. Either way, we need to expose the _BASE keys, so I'll merge that first. Can tackle the concatenation helper as a follow up