feat(utils): Use consts rather than getGlobalObject function

[timfish]

As discussed here, this PR:

• Replaces getGlobalObject with a const GLOBAL_OBJ which retains the runtime detection from feat(utils): Modern implementation of getGlobalObject #5809
• Also includes a WINDOW const which returns GLOBAL_OBJ but with typeof GLOBAL_OBJ & Window type.
  • This will eventually move to @sentry/browser to ensure stricter typing around the global object
  • Maybe this should be called WINDOW_GLOBAL to remove any ambiguity?

It's worth noting that @sentry/node and downstream node code doesn't seem to make use of getGlobalObject and is already using global and I'm not sure if anything is gained by modifying these.

[AbhiPrasad]

hmm I wish we could turn on bundle size bot for you - does this give any savings there?

Also, when this gets to a good place, could we split this up so we change each package one at a time?

[timfish]

One thing that makes this PR a little bit risky is the fact that the TypeScript compilation doesn't seem to complain about the node.js global appearing anywhere. This means there are no warnings if an undefined variable appears anywhere in code named global!

[timfish]

Also, when this gets to a good place, could we split this up so we change each package one at a time?

Yeah, I'll split it up because this PR has become huge!

[timfish]

So bundle.min.js is 83 bytes smaller vs before the changes to getGlobalObject in #5809 🤷‍♂️

[lobsterkatie]

One thing that makes this PR a little bit risky is the fact that the TypeScript compilation doesn't seem to complain about the node.js global appearing anywhere. This means there are no warnings if an undefined variable appears anywhere in code named global!

This feels fishy to me. It should be complaining... Is there a place where you see it in a package which doesn't have node types?

[timfish]

Is there a place where you see it in a package which doesn't have node types?

Just double checked and I can stick global anywhere in utils and there is no compilation error.

I suspect it's because @types/node is in the root node_modules and TypeScript just blindly loads everything in @types/* while following node module resolution.

[timfish]

Closing this in favour of multiple smaller PRs