Consider adding back browser field in v3

v3 removed the browser field, but I believe this should be reconsidered.

The recommended alternative to use cross-fetch is not ideal. Since cross-fetch ships as a ponyfill, any usage via import (import fetch from "cross-fetch") will cause webpack to include an unnecessary cross-fetch ponyfill in the bundle for environments with native fetch.

Scenario: A user is bundling using webpack and depending on an SDK library that uses fetch internally. The SDK library is intended to support both node and modern browsers. Which fetch package should the SDK library use?

• node-fetch v2: Webpack includes browser.js from node-fetch which is a tiny wrapper around the native fetch
• node-fetch v3: Webpack includes src/index.js which is not intended to be used in the browser
• cross-fetch: Webpack includes the entire whatwg-fetch ponyfill and it will be used instead of native fetch

Removing browser.js from this package leaves no way for the SDK library to support modern browsers without also forcing unnecessary code in the end-user bundle

[gr2m]

Also strong negative from me. The "browser" key was never standardized. It’s a made-up key that most JS bundlers adopted, but not consistently. I cannot count the hours of maintenance pain that the “browser” field caused for obscure use cases. It might make your life easier if node-fetch added it, but it’s a gateway to maintenance hell.

Node.js now created a standard that will be a much better fit to server different code for different environments: conditional exports. But to my knowledge none of the bundlers adopted the standard yet.

[bitinn]

Strong negative, node-fetch is never intended for browser side, you are your best judge as to what polyfill / global export / global fetch is acceptable, we should not be the judge.