refactor(cli): refactor js-binding to support easier bundling.

[everett1992]

#1948

This PR addresses two issues I had with using the JavaScript generated by @napi-rs/cli with a bundler.

1. The existsSync check before require breaks if the bundler renames the .node file
2. platform, arch cannot be defined at build time.

With this change esbuild can bundle napi-rs libraries with just --loader:.node=copy and webpack can bundle with node-loader.
Before I was able to use esbuild by disabling asset hashing, but I wasn't able to get webpack working.

Additionally you can define process.arch and process.platform at build time and requires to unused platforms/arch's will be eliminated and not included in the bundle.

[Brooooooklyn]

NAPI-RS had a similar implementation before; but it breaks another tools like ncc on Vercel: napi-rs/node-rs#316

[everett1992]

Do you have a link to that similar implementation?

I tested this PR with @vercel/ncc, esbuild, and webpack with both grouped and separated package binaries.
This implementation seems more likely to work across all bundlers because it doesn't use any require.resolve or file system checks. It's the same pattern you're currently using for separated package binaries, but I use it for both separated and grouped, and skip the file exists check.

 function requireNative() {
  if (process.platform === 'android') {
    if (process.arch === 'arm64') {
      try {
        return require('./rust-cloudauth-core.android-arm64.node')
      } catch (e) {
        loadErrors.push(e)
      }
      try {
        return require('@amzn/rust-cloudauth-core-android-arm64')
      } catch (e) {
        loadErrors.push(e)
      }

[Brooooooklyn]

Do you have a link to that similar implementation?

https://github.com/napi-rs/node-rs/blob/main/packages/helper/src/loader.ts

For loading logic like this:

function requireNative() {
  if (process.platform === 'android') {
    if (process.arch === 'arm64') {
      try {
        return require('./rust-cloudauth-core.android-arm64.node')
      } catch (e) {
        loadErrors.push(e)
      }
      try {
        return require('@amzn/rust-cloudauth-core-android-arm64')
      } catch (e) {
        loadErrors.push(e)
      }

I'm worried that such logic is too dynamic, some packing tools that are not implemented finely may not be able to analyze the actual path/package required.

[everett1992]

Which part are you worried about? I can refactor. The important part is that there is no existsSync check. Changing to if/else helps dead code elimination with define plugins. The requireTuple function reduced duplication, but the generated code is the same. I looked at the old implementation. It's using require.resolve which I found bundlers use as a hint that a module is dynamic and shouldn't be bundled. It's also calling require in a loop with dynamic strings, which bundlers can't figure out.