Alternative export API for optimized delivery

[benoneal]

Just found this library, and I think you guys have nailed the problem that is isomorphic crypto, and the approach appears really well researched and developed. In the interest of optimising real-world application use and making it a bit more user-friendly, I've got some suggestions:

For most projects I've worked on, only one, possibly two crypto methods are required. For these projects, modern tree-shaking build systems can optimise application code by removing unused code paths.

Unfortunately, right now Enigma's module pattern appears to prevent that, as destructured imports (import {AES} from '@cubbit/enigma) aren't valid, and import Enigma means bundling the entire library, even though the vast majority of that code will never be used.

On a related note, the new Enigma.AES().init({key}).then(aes => aes.encrypt(message)) API seems unnecessarily unwieldy. Surely static async methods such as AES.encrypt(message, key) should be possible?

Otherwise I'd hazard that most people, like me, will have to write our own convenience wrappers around that API.

But the tree-shaking thing is more important, as it's not possible to address in userland, and some applications (like ours!) are very sensitive to the size of our script payloads.

[alessiopcc]

Thanks for suggestions. We will try to address it in the next version.
We can improve imports to better support tree shaking, I think we need to refactor the init phase to do it.

Regarding the encrypt method, yes it's unwieldy but it is due to the WebCrypto implementation. We started with a single static method but then we noticed bad performance encrypting multiple times with the same key because of the WebCrypto importKey. We can add back the static method and let the choice to users.