Overuse of getGlobalObject<T>()?

[timfish]

getGlobalObject seems to be overused throughout the SDKs. Why not use window in @sentry/browser and global in @sentry/node? What context/knowledge am I missing?

getGlobalObject was clearly designed to help get the global object when the code might be run on different runtimes (ie. frontend and backend) but those usages are minimal.

In many cases, it appears to be used to help extend the global type like this:

sentry-javascript/packages/nextjs/src/performance/client.ts

Lines 14 to 20 in 903addf

	const global = getGlobalObject<
	Window & {
	__BUILD_MANIFEST?: {
	sortedPages?: string[];
	};
	}
	>();

sentry-javascript/packages/nextjs/src/performance/client.ts

Line 202 in 903addf

const pageRoutes = (global.__BUILD_MANIFEST || {}).sortedPages;

But you can extend the global via declare global so the types work and simply use window:

declare global {
  const __BUILD_MANIFEST: { sortedPages?: string[] } | undefined;
}

const pageRoutes = (window.__BUILD_MANIFEST || {}).sortedPages; 

Do we avoid using declare global for the below global properties because this leaks into the global type for consumers of the SDKs?

sentry-javascript/packages/utils/src/global.ts

Lines 13 to 27 in 903addf

	interface SentryGlobal {
	Sentry?: {
	Integrations?: Integration[];
	};
	SENTRY_ENVIRONMENT?: string;
	SENTRY_DSN?: string;
	SENTRY_RELEASE?: {
	id?: string;
	};
	__SENTRY__: {
	globalEventProcessors: any;
	hub: any;
	logger: any;
	};
	}

[AbhiPrasad]

As per a @kamilogorek knowledge bomb on slack:

getGlobalObject seems to be overused throughout the SDKs. Why not use window in @sentry/browser and global in @sentry/node? What context/knowledge am I missing?

• There is no window in WebWorker
• There used to be no window in jest/phantomjs
• There is no window in some obscure "compile-to" native environments
• Also some of the code that uses getGlobalObject is shared across all SDKs, so we cannot choose for browser/node, the util has to do it
• eg. getMainCarrier in hub uses it, and its shared for node/browser
• And our main logger uses it as well
• So effectively it has to be there. And if its there, why not use it everywhere instead of sometimes global in node, sometimes window in browser, sometimes getGlobalObject. Unification here is better, as you can easily grep for global API usages
• It wont make bundle larger, as its there. And as for performance, its a single op for existence check, 0 overhead basically