Add a way to auto-detect JS package for imports

[mydea]

Currently, for code snippets in the JavaScript SDKs, if we want to have fully correct snippets for the different packages, you have to have a slightly different snippet for each:

// Browser JS
import * as Sentry from '@sentry/browser';

Sentry.init({
  // more stuff comes here...
});

vs.

// Browser JS
import * as Sentry from '@sentry/angular';

Sentry.init({
  // more stuff comes here...
});

etc. In many cases, the only thing that has to be changed is the package name itself. It would be very helpful to have a code helper similar to ___PUBLIC_DSN___ that could be used in a code block that would automatically resolve to the correct package - or some other way to solve this. I'm thinking of something like:

// Browser JS
import * as Sentry from '__SENTRY_JS_PACKAGE__';

Sentry.init({
  // more stuff comes here...
});

This would help to cut down on code duplication quite a lot. Noticed this again e.g. here: https://github.com/getsentry/sentry-docs/pull/9005 Where this is basically the only customization that has to be done for each package, but it makes keeping stuff in sync much harder.

[chargome]

@mydea We realised today that all of these very similiar code snippets often still differ (e.g. different names for config files that are also framework specific). So I'm not sure if we would be even able to apply this feature broadly – do you think it is worthwhile to still pursue this feature? We could for example also define standard filenames for client and server for each framework and inject that there. Let me know what you think!

[mydea]

I think there are still some examples where there are no changes, but not sure how many. If this is hard to implement, feel free to disregard. If it is easy, it would still be nice/helpful imho!

[chargome]

Let's see if we encounter more of this in the near future. For the file name issue, I don't want to pass this around using frontmatter since this becomes a bit messy and is hard to understand for people that do not know the codebase. I would argue that we should keep content mutation as simple as possible for everyone.

Closing this for now, but we can always build upon the closed PR if we want to re-visit this.