Alternative for "browser" key with higher priority

I’ve stumbled upon this issue in https://github.com/mwilliamson/mammoth.js/pull/106

browser key is widely used for defining which file should be used in browser environment. Some tools might use this field optionally, but they also have an alternative which is tool-specific, for instance, in webpack.

Could you add support for something like browserify.browser with higher priority in addition to browser?

[ljharb]

I don’t see any harm, other than added complexity, of adding such a key - but since all the bundlers and ecosystem tools expect this definition of the “browser” field, i don’t think it would be beneficial for authors - anyone using the browser field for the purpose you describe would end up getting bug reports from the majority of the ecosystem.

In other words, adding a “browserify” key won’t change the reality that “browser” already has a permanent meaning, and that for your use case, you’d want a custom field name regardless.

[nazar-pc]

Right now D3 doesn’t use browser field at all. Not sure why, but in past they have clearly used it for specifying browser build separately from Node.js build: https://github.com/d3/d3/blob/c57952f349dff8bb8035316cedc8878bf7d8b97e/package.json#L18-L19

  "main": "build/d3.node.js",
  "browser": "build/d3.js",

I did a mini-research on common fields about ~1.5-2 years ago and wouldn’t bother to do it again, but back then there were more projects like that.

I think if at this point you are still not convinced to scope browserify’s stuff under browserify key (which by the way already exists) even optionally as other projects do, then I’m disappointed and have really nothing to add.