Better packaging utilizing package.json browser field

[larixer]

Provide compiled sources from 'lib' for node modules. Provide all API exports from index.js.

This is breaking change.

As a side effect this change fixes file paths in Stack Traces when react-apollo throws exceptions.

[tmeasday]

@jbaxleyiii are you OK with these changes?

[jbaxleyiii]

@tmeasday I'm still concerned with the over shipping to clients. Not all packages respect the browser field in package.json. (AFAIK Meteor doesn't even support it?). I don't think it's worth the potential extra shipping to save a / in the import?

[stubailo]

Meteor definitely honors the browser field! AFAIK Webpack and Browserify do too. I don't know about stuff like Rollup.

[larixer]

@stubailo Rollup supports it too, in the node resolve plugin:
https://github.com/rollup/rollup-plugin-node-resolve

[larixer]

@jbaxleyiii

I don't think it's worth the potential extra shipping to save a / in the import?

Well, I'm not only trying to save '/' in the import.
The goals are the following:

1. Fix Stack Traces.
2. Discourage people to use private package methods, located in files after / in the import.
3. Ship only relevant package files, don't ship things like scripts folder or .travis.yml file, that are non-relevant for npm module. But ship src folder contents, that is needed to understand stack traces.
4. Moving compiled files outside of target compilation folder breaks TypeScript typings optimizations. If files were where they compiled to, we could provide typings for 3rd party libs, like redux compose (to not require all the redux lib, but only compose function). I will submit PR that does so, after this PR will be merged.

[jbaxleyiii]

Alright I'm game then!

[tmeasday]

Thanks for working hard to get this through @Vlasenko

[tmeasday]

@Vlasenko any idea why master is now failing w/

Invariant Violation: ReactCompositeComponent: injectEnvironment() can only be called once.

It passed before I merged this PR and the PR itself passed :/

[larixer]

@tmeasday I think injectEnvironment is not related to this PR, but rather related to another PR and I have even left comment with caution about my observations:
#305 (comment)

[larixer]

@tmeasday Though at this stage, I think you can just upgrade everything to [email protected] instead.

[tmeasday]

With 15.4 I started seeing a whole lot of warnings like:

jest-haste-map: duplicate manual mock found:
  Module name: ErrorUtils
  Duplicate Mock path: /Users/tom/Apollo/react-apollo/node_modules/react/node_modules/fbjs/lib/__mocks__/ErrorUtils.js
This warning is caused by two manual mock files with the same file name.
Jest will use the mock file found in:
/Users/tom/Apollo/react-apollo/node_modules/react/node_modules/fbjs/lib/__mocks__/ErrorUtils.js
 Please delete one of the following two files:
 /Users/tom/Apollo/react-apollo/node_modules/react-native/Libraries/Utilities/__mocks__/ErrorUtils.js
/Users/tom/Apollo/react-apollo/node_modules/react/node_modules/fbjs/lib/__mocks__/ErrorUtils.js

And ultimately errors like:

    Cannot find module 'ReactNativeDefaultInjection' from 'setup.js'

Simply bumping the react-test-renderer dep to the rc works for now, until we resolve the above.

[tmeasday]

Ahh, the problem was react-native doesn't yet support [email protected], except in a pre-release. Bumping to that.

[larixer]

@tmeasday Yeah, somehow this all is not surprising :)
http://i.imgur.com/KzCHMAx.gifv

[tmeasday]

I blame npm, as always. Although in their defence I did ignore a peer dep warning (which they've conditioned me to do)