Inline util.format and replace usage of global

[stevehobbsdev]

Changes

This PR inlines the usage of util.format and removes the need to pull in the native util module. This fixes environments like Webpack 5 that no longer automatically polyfills such native modules.

It also replaces the usage of global with window, the again the defaults around providing this in Webpack 5 have changed. However, this library was incorrectly using global where it should have just used window.

References

Fixes #1999

Testing

• This change adds unit test coverage
• This change adds integration test coverage
• This change has been tested on the latest version of the platform/language

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All code quality tools/guidelines have been run/followed
• All relevant assets have been compiled

[lgtm-com]

This pull request introduces 2 alerts when merging a35337d into 2dd24fa - view on LGTM.com

new alerts:

• 1 for Comparison between inconvertible types
• 1 for Unneeded defensive code

[lgtm-com]

This pull request introduces 2 alerts when merging 171ff6c into 2dd24fa - view on LGTM.com

new alerts:

• 1 for Comparison between inconvertible types
• 1 for Unneeded defensive code

[adamjmcgrath]

I'm assuming it's ok that these snapshots have changed? The new output looks better...

[stevehobbsdev]

These appear to change depending on the version of node that generates the snapshots. I think with Node 10 you get the former version, but newer versions omit the wrapping [' ']. The output on the actual screen is the same though. These just snuck in from a previous check-in.

[GlebVST]

Hey @stevehobbsdev so apparently this change from global to window could break some apps using auth0 lock (as it did our) in server-side-rendering environment (where you have no window basically), you guys sure this was good for a minor version change??

[stevehobbsdev]

@GlebVST Sorry to hear that we may have inadvertently broken you; we believed it to be a fairly innocuous change given the use cases we support. Which SSR environment/framework are you using?

SSR isn't an officially supported use case for Lock; normally I would suggest configuring your app in such a way that it ignores Lock for the SSR build, if that's possible. In the meantime I would pin to 11.30.4 until a resoultion can be found.

[GlebVST]

@stevehobbsdev err it's a bit of surprise to know SSR is not supported, after like 4 years we're using it ;) Yeah it's a bit dated React app where Lock is just used on a login component that gets rendered by node/express when people land on /login path - not quite sure why such usage would be out of support?
Right, rolled back to 11.30.4 for now...