Throw useful error if `atob` / `btoa` are not defined

[gr2m]

universal-github-app-jwt is a universal library with different code for Node/Browser. It has a "browser" key to override the entry point for browser builds:

universal-github-app-jwt/package.json

Lines 4 to 6 in ac358a2

	"browser": {
	"./pkg/dist-src/get-token.js": "./pkg/dist-src/get-token-browser.js"
	},

Unfortunately build tools such as WebPack end up using this entry point, too, even when building for Node targets. See for example: octokit/auth-app.js#59. There has been a lot of discussion around this topic, but no conclusion on how to resolve it.

But the least we could do is to check if atob exists in src/utils.ts. If it doesn't, then throw a helpful error which could include a link to the README file where we could add some information about this challenge.

[copperwall]

Hey @gr2m 👋

I'm up to work on this. Do you think it'd be helpful to try and discover the environment that the program is running in and either use atob/btoa or Buffer.from('base64')/buffer.toString('base64') based on whether its a browser or node?

[gr2m]

I think if atob/btoa does not exist we can be sure that the code is running in Node. The challenge is that I don't want the bundle size to increase for browsers ... but I guess Buffer is just a global in Node now, so we don't need to require anything, right? I'd just want us to check the bundle sizes using different bundlers, to see if they add some polyfil code to make Buffer available in browsers

[copperwall]

Yeah that makes sense to me. It'd be really convenient if the node branch just relied on the native Buffer without polyfilling it (and just ignoring it in the browser case). I'll give this a try and see what webpack/parcel/snowpack do.

[swain]

build tools such as WebPack end up using this entry point, too, even when building for Node targets.

@gr2m is this correct? The docs seem to say that webpack uses module by default for node targets, not browser.