browserify-optional is messing with browserify's ability to process es6

[daviddias]

Following #70, now I'm unable to browserify any module that needs libp2p-crypto, as it just rejects anything that is es6. Adding babelify doesn't make it work either.

[daviddias]

I believe that it isn't clear what this library is optimizing for. Currently, we have two dependencies that are causing a lot of friction in the adoption path of js-ipfs:

• libp2p-crypto-secp256k1, which is not bundled by default to avoid increased bundle size (valid concern). This decision has created a lot of pain for browserify users.
• node-webcrypto-ossl, which requires a compilation step, creating some hurdles for electron, windows and linux users -- Run tests inside electron Node.js and Browser process as well ipfs/js-ipfs#697 -- Windows support ipfs-inactive/js-ipfs-http-client#416. Some of these issues were mitigated, but not 100% (being 100% that no user has a issue.)

We need to step up our process when it comes to merging and releasing things that are so sensitive that can break DX. @dignifiedquire let's talk soon and make a clear roadmap from all of the issues identified and understand what needs to be done for libp2p-crypto, I know you have some good thoughts and I want to help you make these happen.

Meanwhile, because I want to avoid creating problems to our users, I'll go ahead and include libp2p-crypto-secp256k1 as a dep of the project, avoid breaking support.

[daviddias]

One more note, just spent some time getting out of the circular dependency of libp2p-crypto and libp2p-crypto-secp256k1, why isn't this DI?

[dignifiedquire]

proper fix in

• refactor: loading of additional key support #74
• adjust to new loading of dynamic key adding to libp2p-crypto js-libp2p-crypto-secp256k1#3

[daviddias]

not an issue anymore