Skip to content

Implement Node Core SDK #15213

Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject

Description

@mydea
mydea
opened on Jan 29, 2025

Description

Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.

While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:

  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things

For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)

With this, users could choose to do:

import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});

And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.

We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.

Notes / Thoughts

Some additional pointers for implementation:

  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today

Metadata

Metadata

Assignees

Labels

Node.jsProject

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Implement Node Core SDK · Issue #15213 · getsentry/sentry-javascript · GitHub
Skip to content
Implement Node Core SDK #15213
Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject
Description
@mydea
mydea
opened on Jan 29, 2025
Description
Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.
While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:
  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things
For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)
With this, users could choose to do:
import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});
And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.
We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.
Notes / Thoughts
Some additional pointers for implementation:
  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
Metadata
Metadata
Assignees
Labels
Node.jsProject
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement Node Core SDK · Issue #15213 · getsentry/sentry-javascript · GitHub
Skip to content
Implement Node Core SDK #15213
Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject
Description
@mydea
mydea
opened on Jan 29, 2025
Description
Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.
While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:
  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things
For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)
With this, users could choose to do:
import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});
And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.
We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.
Notes / Thoughts
Some additional pointers for implementation:
  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
Metadata
Metadata
Assignees
Labels
Node.jsProject
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement Node Core SDK · Issue #15213 · getsentry/sentry-javascript · GitHub
Skip to content
Implement Node Core SDK #15213
Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject
Description
@mydea
mydea
opened on Jan 29, 2025
Description
Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.
While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:
  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things
For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)
With this, users could choose to do:
import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});
And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.
We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.
Notes / Thoughts
Some additional pointers for implementation:
  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
Metadata
Metadata
Assignees
Labels
Node.jsProject
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Implement Node Core SDK · Issue #15213 · getsentry/sentry-javascript · GitHub
Skip to content
Implement Node Core SDK #15213
Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject
Description
@mydea
mydea
opened on Jan 29, 2025
Description
Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.
While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:
  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things
For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)
With this, users could choose to do:
import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});
And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.
We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.
Notes / Thoughts
Some additional pointers for implementation:
  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
Metadata
Metadata
Assignees
Labels
Node.jsProject
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement Node Core SDK · Issue #15213 · getsentry/sentry-javascript · GitHub
Skip to content
Implement Node Core SDK #15213
Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject
Description
@mydea
mydea
opened on Jan 29, 2025
Description
Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.
While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:
  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things
For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)
With this, users could choose to do:
import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});
And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.
We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.
Notes / Thoughts
Some additional pointers for implementation:
  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
Metadata
Metadata
Assignees
Labels
Node.jsProject
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Implement Node Core SDK · Issue #15213 · getsentry/sentry-javascript · GitHub
Skip to content
Implement Node Core SDK #15213
Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject
Description
@mydea
mydea
opened on Jan 29, 2025
Description
Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.
While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:
  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things
For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)
With this, users could choose to do:
import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});
And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.
We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.
Notes / Thoughts
Some additional pointers for implementation:
  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
Metadata
Metadata
Assignees
Labels
Node.jsProject
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Implement Node Core SDK · Issue #15213 · getsentry/sentry-javascript · GitHub
Skip to content
Implement Node Core SDK #15213
Closed
Closed
Implement Node Core SDK#15213
Assignees
andreiborza
Labels
Node.jsProject
Description
@mydea
mydea
opened on Jan 29, 2025
Description
Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.
While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:
  1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
  2. Users who have their own OTEL setup may run into problems with conflicts of versions
  3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things
For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)
With this, users could choose to do:
import*asSentryfrom'@sentry/node-core';Sentry.init({dsn: 'xxx',});
And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.
We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.
Notes / Thoughts
Some additional pointers for implementation:
  • The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
Metadata
Metadata
Assignees
Labels
Node.jsProject
Projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Issue actions