browser field spec for package.json

browser.md

The spec has moved to a repo: https://github.com/defunctzombie/package-browser-field-spec to facilitate collaboration.

If that is the case then it would indeed be better for the npm documentation to be updated so that it is correct.

It seems like this would be better if it followed the same conventions as the npm exports field? It doesn't seem to have any wildcard/regex abilities unless I'm missing something.

The exports field has zero to do with npm; that’s a node-specific field that was added almost a decade after the browser field became a de facto standard.

@ljharb I wasn't referring to the history of it - I just think it would be nice if the browser field allowed for pattern replacement so I don't have to input every filename into the package file. Maybe Webpack/Browserify should adopt the exports convention - that's all I'm saying. It would make for cleaner code.

The exports field does have the "browser" condition, but it doesn't seem like webpack or browserify pays attention to it.

see the difference:

"exports": {
  ".": {
    "browser": "./lib/core.js",
    "node": "./lib/core-node.js"
  },
  "./*/": "./lib/*/",
  "./*": "./lib/*.js"
},
"browser": {
  ".": "./lib/core.js",
  "evented": "./lib/evented.js",
  "fig": "./lib/fig.js",
  "heap": "./lib/heap.js",
  "lock": "./lib/lock.js",
  "middle": "./lib/middle.js",
  "mixin": "./lib/mixin.js",
  "pipe": "./lib/pipe.js",
  "query": "./lib/query.js",
  "router": "./lib/router.js",
  "tree": "./lib/tree.js"
}

Ok, it appears I was missing something. WP5 does have support for the exports field. Although I'm stuck with WP4 - but I found this plugin https://www.npmjs.com/package/@builder/exports-field-webpack-plugin will test and see how it goes

That's a no-go -- tried it in Nuxt and it broke some things. Guess I'll just have to be verbose. Oh well ¯_(ツ)_/¯

The original idea behind the browser field is different from the exports field. With the browser field the purpose was not to wholesale ship a different set of files for node vs browser but instead provide a mechanism to replace a few files when packaging for browser. The thinking being that you would generally share 90% of the code and only replace a few compatibility or platform files. Ideally these wouldn't even be user-facing but could be.

I'm building libraries that work in the browser and in Node. I get the original purpose of the browser field, but now that the browser is getting more advanced, the use cases are getting more advanced. WP5 is using the exports field with pattern replacement. I'm not sure about Browserify, but I'd like to make libs that work with both. It's not a huge deal, I can just define every file, but that definitely seems like an inefficient way to do it in the grand scheme

The efficient thing to do is to have most of your files be universal, and have a very small number that vary by platform - ideally confined to separate packages.

My files are isomorphic, meaning they work on both browser and in Node, I'd call that "universal". The issue is that Webpack (4) doesn't care, and so I have to compensate by listing every file in the browser field. I have one file that is used on Node only and the exports field handles that just fine.

The efficient thing would be to allow for the browser field to behave like the exports field. But less efficient for me to use my time trying to get that changed than just to deal with it. But as my libs grow, so too must the exports field. Tracking each import in the config is redundant and therefore inefficient. Hopefully Browserify/Webpack will address this. But I won't be holding my breath.