Repository: electron
Issue: [Feature Request] Provide an easy means for getting highest supported N-API version for given Electron version
Labels: enhancement :sparkles:,component/node-integration

<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:**
  * 11.2.3
* **Operating System:**
  * Windows 10 2004 x64
* **Last Known Working Electron version:**
  * N/A

### The feature request
<!-- A clear and concise description of what you expected to happen. -->

Native Node libraries have the option to provide prebuilt binaries. An example is `lovell/sharp`. Up until [version 0.25.4](https://github.com/lovell/sharp/releases/tag/v0.25.4) of the library, it had 74 (!) prebuilt assets, for every Node/Electron ABI version. They have now switched to N-API-only (supported by both NodeJS and Electron), [resulting in much less (8) prebuilt assets](https://github.com/lovell/sharp/releases/tag/v0.27.1).

While this is great, and `prebuild-install` automatically selects the correct N-API version for the given Node version (more on that below), this doesn't work for Electron. It still tries to get the prebuild for the given Electron ABI version instead of its N-API version, which now returns a 404 since there are only N-API prebuilds:

```
prebuild-install http request GET https://github.com/lovell/sharp/releases/download/v0.27.1/sharp-v0.27.1-electron-v85-win32-x64.tar.gz
prebuild-install http 404 https://github.com/lovell/sharp/releases/download/v0.27.1/sharp-v0.27.1-electron-v85-win32-x64.tar.gz
```

#### Potential fix/workaround

A potential fix for this [is in the works here](https://github.com/develar/app-builder/pull/47), but it simply looks at the first item in the `binary.napi_versions` section of a library's `package.json` ([example from `lovell/sharp`](https://github.com/lovell/sharp/blob/v0.27.1/package.json#L158-L162)). While this works great for libraries that only support a single N-API version, it might become problematic if it supports multiple N-API versions, where some functionality is only available in higher N-API versions. Because it takes the first N-API version it finds, it might take e.g. version 3 while it could have worked with version 6 in the case of Electron 11.

#### Moving forward: easily recognizing supported N-API version for given Electron version

It would be great to have a static means of getting the highest supported N-API version for a given Electron version. It is already possible to receive the highest supported N-API version within an Electron process by accessing `process.versions.napi`, but that requires Electron to be started.

`electron-builder`/`prebuild-install` [leverage](https://github.com/electron-userland/electron-builder/blob/be4a1fb05b6734800aa97652e856de1308e4a2f2/packages/app-builder-lib/src/electron/electronVersion.ts#L26-L38) Electron's `package.json` to get the Electron version, and use that to set the `target` version for prebuilds. The highest supported N-API version isn't mentioned in the `package.json`, so AFAIK there's no way to retrieve Electron's N-API version without running Electron itself first. `lovell/sharp` [worked around this](https://github.com/lovell/sharp/commit/dcc42f85148ba3697c6b56f803c485013c0ca29b) by explicitly setting `npm_config_target=3` in their `package.json`. However, this won't help them as soon as they need to support multiple N-API versions. 

`napi_build_utils` [has a function called `getBestNapiBuildVersion`](https://github.com/inspiredware/napi-build-utils/blob/562e714a4b53d0c530c52e9c76c2b3e9e81589cf/index.js#L166-L179) - it checks a package's `binary.napi_versions` array and compares them to Node's `process.versions.napi`. So if a native package supports N-API versions 3, 6 and 7, and the current NodeJS version is 14 which supports N-API 7, it will select N-API 7 as the version to build against (or to get the prebuilt binaries for it).

It would be fantastic if the Electron team could implement one or more of the following options:
- Provide the highest supported N-API version in Electron's `package.json` (the same value that can be retrieved through `process.versions.napi`)
- Provide the highest supported N-API version in Electron's `dist` folder (it currently already has a `version` file in that folder, which contains Electron's version number)
- Provide a CLI switch `electron --napi`, just like you can do `electron --version` and `electron --abi` nowadays

I'm happy to help with this if someone could point me in the right direction as to where the things above are defined.

<!--
For bugs that can be encapsulated in a small experiment, you can use Electron Fiddle (https://github.com/electron/fiddle) to publish your example to a GitHub Gist and link it your bug report.
-->

<!--
If Fiddle is insufficient to produce an example, please provide an example REPOSITORY that can be cloned and run. You can fork electron-quick-start (https://github.com/electron/electron-quick-start) and include a link to the branch with your changes.
-->

<!--
If you provide a URL, please list the commands required to clone/setup/run your repo e.g.
```sh
$ git clone $YOUR_URL -b $BRANCH
$ npm install
$ npm start || electron .
```
-->

### Screenshots
<!-- If applicable, add screenshots to help explain your problem. -->

N/A, see `prebuild-install` command example above

### Additional Information
<!-- Add any other context about the problem here. -->