feature: resolve main reference to other modules

[pemrouz]

Related: https://github.com/defunctzombie/node-browser-resolve/issues/83

Notes:

• I tried to keep changes to a minimal

• I reused this check to differentiate references to module/file.

  This does mean that there are a number modules that specify "browser": "browser.js" which would be invalid. It seems better to try align this with how require works for less confusion in the long-term (i.e. require('./browser.js') vs require('browser.js'), but if there is a lot of breakage an additional check could always be added for .js. I'm happy to go on a PR-spree for the browserify modules that do this.

• The tests added pin down behaviour for the following few use cases:
  • browserify . on a module which has browser set to another module
  • browserify main.js (where main.js is referenced by main in package.json)
  • require('module-a') from module-b (note: the replacement for module-a is resolved relative to itself)

[defunctzombie]

@substack @sokra @Rich-Harris for additional review

[pemrouz]

bumping.. is there anything else required before we can land this?

[pemrouz]

@defunctzombie ..?

[dy]

@defunctzombie @sokra @Rich-Harris ping

[goto-bus-stop]

This does mean that there are a number modules that specify "browser": "browser.js" which would be invalid.

i don't have numbers on this but i've definitely seen it in the wild so support for that should not be dropped.

it looks like "browser": "barename" did not previously resolve to ./barename.js so that change should be safe.

[goto-bus-stop]

@pemrouz if you're still interested in working on this i can review later this week. no guarantees that defunctzombie will have time in the near future to do merges/releases ofc :)

i don't think webpack uses browser-resolve these days, unsure about rollup. it'd be good to check if webpack's enhanced-resolve already supports this too.