Braintree-web: Convert to ECMAScript modules for tree shaking support

[dimitarnestorov]

Tools like webpack and parcel have a feature called tree shaking allowing me to automatically remove dead code from modules. However it relies on ECMAScript modules.

For example since our app doesn't use Google Pay or Apple Pay but we're still shipping code for those providers, resulting in a larger bundle, resulting in slower load times.

[719media]

You should be able to get similar results from just importing the files like so:

//we only want paypal support, so don't include the whole shebang
//import braintree from 'braintree';
import braintreeClient from 'braintree-web/client';
import braintreePaymentRequest from 'braintree-web/paypal-checkout';

I agree it would be nicer to not have to do this, or be able to do import { client } from 'braintree'; without getting all the additional libs, but perhaps this may be of use to you in the interim

[crookedneighbor]

Thought I responded to this, but I guess not.

@719media is correct, that's our recommended way of importing just the components you need.

We can't support ECMAScript modules at this time, because it would break users who are using older versions of build tools that rely on the commonjs require style. I've added a v4 label to this issue so we can keep track of it when we're ready to do a major version bump.

[maxisam]

Well, if you guys use Typescript, you can create different builds for different users. And we can have official type support at the same time.

https://stackoverflow.com/questions/30439869/can-typescript-compile-to-es6-code

[crookedneighbor]

We are not using Typescript at this time. We are considering it for the next major version. Thanks for the resource!

[chase-moskal]

We are considering it for the next major version.

typescript or not, it's not a breaking change, so this could be included in the next minor version

typescript is an excellent choice, but is not necessary for this task -- we just want something like a dist-esm/ directory containing a converted copy of the library

at this point, for my application, i have to run a build step to convert your library into es modules — it would be much better for that build step to happen in this library's repo, so we can ship the results and save everybody the same hassle

check out the pika ecosystem to learn how to become compatible (package json "module" and "type" fields)