Possible bug: relative paths in the "browser" field are interpreted as package paths

Context: I’m the author of esbuild, a JavaScript bundler, and I’m currently working on a bug in esbuild related to the browser field: https://github.com/evanw/esbuild/issues/740. The discussion referenced behavior differences between Browserify and Webpack. I believe the problem in this issue is a bug in Browserify, so I am re-reporting it here in case you weren’t already aware of it.

A demonstration of the bug is here: https://github.com/evanw/browserify-package.json-browser-bug. This contains a call to require('foo/bar') and a package.json file with "browser": { "./foo/bar": "./foo_bar.js" }. Webpack does not apply this remapping but Browserify does. This seems like a bug in Browserify to me since there is nothing at the path ./foo/bar. The path to the underlying file this case is either a relative path of ./node_modules/foo/bar or a package path of foo/bar but not a relative path of ./foo/bar.

[ljharb]

Nothing need be present at that location. In this example, require('package/foo/bar') would throw in node but load package/foo_bar.js in the browser.

[dsyer]

I think I have encountered this bug as well. I see a lot of places in browserify where '/' is prepended to a package path. So if you do this

$ node_modules/browserify/bin/cmd.js -r ./hello.js > bundle.js

then bundle.js has this

require=(function()...)()({"/hello.js":[...]},{},[]);

I.e. the leading ‘./’ is stripped and replaced with ‘/’. That explains why a relative path and a package path are equivalent. It also breaks require('./hello.js') in code that imports bundle.js. I can see tests in browserify (like externalize) which appear to work but I can’t really understand how.

The example in the README (https://github.com/browserify/browserify#external-requires) would also break if you wanted to require('./my-file.js') instead of require('my-module').