NextJS SDK takes a long time to import

[AbhiPrasad]

const before = Date.now();
await import("@sentry/nextjs")
console.log(Date.now() - before)

Was reported to take 240ms. Let's try to figure out why!

• Node 18
• Latest Next.js (and it's webpack)

[lforst]

After some profiling it seems that our require chains take a lot of time, probably because we have preserveModules set to true. We should investigate if making the switch is worth it 👀 @AbhiPrasad

[timfish]

If we bundle @sentry/node should bundle just the @sentry* dependencies or all the otel stuff too?

Bundling core/browser is relatively easy. I just tested @sentry/browser and it outputs a 1MB ESM file.

However, nextjs is more difficult since it has many files that need to remain not bundled (ie. templates and loaders) and the paths to those need to be preserved.

My main concern with bundling @sentry/node and @sentry/browser is that this could break things where we store in globals in @sentry/core.

For example if everything is bundled, the below globals will we be different if you import from @sentry/core or they're accessed from the browser or node SDKs. This has an impact on downstream SDKs or any users that import from @sentry/core:

sentry-javascript/packages/core/src/integration.ts

Line 24 in 6ddbba6

export const installedIntegrations: string[] = [];

sentry-javascript/packages/core/src/currentScopes.ts

Lines 7 to 11 in 6ddbba6

	/**
	* The global scope is kept in this module.
	* When accessing it, we'll make sure to set one if none is currently present.
	*/
	let globalScope: Scope | undefined;

sentry-javascript/packages/core/src/metrics/exports.ts

Lines 26 to 29 in 6ddbba6

	/**
	* A metrics aggregator instance per Client.
	*/
	let globalMetricsAggregators: WeakMap<Client, MetricsAggregatorInterface> | undefined;

To work around this we would need to move these to the __SENTRY__ global and then ideally have some lints that deny us making any future globals!

[lforst]

Just wanna make sure we are aligned. This is not about bundling everything into one. This is just about changing the output structure of our packages to be a single file (1 for each esm and cjs). The goal here is not to bundle e.g. node and all of it's dependenices into one.

[AbhiPrasad]

We've changed what we can with bundling, going to close this issue.