fix #47 browser hint for 'Long' module

[watsoncj]

Browser hint for webpack and browserify for where to load the "Long" module.

The "index.js": "bytebuffer/dist/ByteBufferAB.js" line is effectively doing the same thing as the previous "browser": "dist/ByteBufferAB.js". It's used in conjunction with the main option and is necessary since the browser property is overloaded.

The Long mapping should help avoid renaming the AMD module.

[dcodeIO]

I see, but index.js contains some code that is not desirable to have in the browser. index.js targets node, that's why there is "browser": "dist/ByteBufferAB.js". Any ideas? Or isn't that a problem at all because every tooling around (not just webpack) will resolve index.js that way?

[watsoncj]

This mapping causes ByteBufferAB.js to be bundled instead of index.js for browser

Testing this change in webpack; ByteBufferAB.JS was bundled. index.js was NOT bundled.

The comments in the "browser field spec" indicate that browserify implements the same behavior.

I'm still unclear if relative paths are resolved identically by all bundlers (webpack & browserify).

[watsoncj]

The browserify handbook documents a slightly different behavior with relative paths. This PR needs to be tested in browserify before merging.

[englercj]

This doesn't look browserify safe, also the Long value should not be in this module. It should be resolved by long's package.json.

[watsoncj]

Thanks @englercj, the issue I was trying to address is getting webpack to use node_modules/long as the provider of Long.

[watsoncj]

This will break browserify and isn't a great solution. See comments about resolve aliases and script-loaders on #47.