Reduce bundle size of the SDK and/or make it treeshakable

[minht11]

The bundle size of the Iterable SDK minified is 294kb which is very large, some apps are smaller than this.

One way to reduce size of the library would be to make it more treeshable, if for example some feature is not used it could be stripped from the final bundle, maybe they could be opt in, for example if users only use tracking and not notifications and so on.

[minht11]

https://github.com/Iterable/iterable-web-sdk/blob/e51f10f7e95dd2c1bc2bb0b8f1555d272c1bdad2/src/inapp/inapp.ts#L670-L672 Lodash is huge library, but only used once for set which could be replaced with setting property directly.

Yup library is used in very few places and could easily replaced with https://valibot.dev/ treeskable, very small bundle size alternative

uuid can be replaced with native crypto.generateRandomUUID

Axios could be replaced with native fetch, though that might be breaking change, not quite sure.

[martinmckenna]

This doesn't exist in the current README (but should still be applicable at this time):

https://github.com/Iterable/iterable-web-sdk/blob/221a5b17e09212a7cef437378743b2d4712b3083/README.md#a-note-about-imports

If you import functions from their direct path, your app should only bundle the code you're using.

So this:

import { getInAppMessages } from '@iterable/web-sdk/dist/inapp';

instead of this:

import { getInAppMessages } from '@iterable/web-sdk';

But yeah updating the package.json with sideEffects: false would also enable tree shaking. In the meantime, I'd use that approach tho ^^

[minht11]

I am lazily importing Iterable, though I might be impacted by https://github.com/rollup/rollup/issues/5410 bug, my bad about treeshaking part, though there are still low hanging fruits which could be optimized.

[mprew97]

Opened a PR to enable tree-shaking here. Will cut a separate ticket for addressing some of the larger packages usage.