removing module export from package.json

[alexreardon]

Currently the module export in package.json includes flow code. This is probably not expected. Given that memoize-one has no dependencies there seems to be little utility at this stage in having a module export.

[codecov-io]

Codecov Report

Merging #9 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master     #9   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines          15     15           
=====================================
  Hits           15     15

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dc4d5a4...dbd9f1f. Read the comment docs.

[alexreardon]

I have been thinking about whether this should be a major or minor version bump. This one is tricky. I have gone back and forth. Module loaders should automatically look for the 'main' export if it cannot find a module. However, if you had a setup that you explicitly requested the module export then their code would break as that export no longer exists.

[alexreardon]

From SemVer.org:

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

I am not 100% sure if module in the package.json is considered 'public api'

[alexreardon]

Given that some people might be explicitly relying on module this change would break them. To be super safe I will make this a major version bump

[leandrowd]

@alexreardon, IMHO, I think you don't need to do this! Consumers can decide whether they want es6 or not. If the answer is NO es6 libraries, the right approach would be to remove "module" from webpack config. If the answer is YES, allow a few directories inside node_modules to go through babel. cc @marcodejongh

[alexreardon]

@leandrowd it might be unexpected that the es6 module contains flow types which is why I am being really simple and just removing it. In this case there is really no advantage in having module as this library has no dependencies. I see the main use case for module being dependency tree shaking - which is not required for this library

[leandrowd]

Fair enough @alexreardon.

[alexreardon]

Users will still have the correct flow types because of the copying of index.flow.js into lib 👍