feat: use UMD instead of IIFE for browser target

[himynameisdave]

Explanation About What Code Achieves:

This is an attempt to fix https://github.com/frappe/charts/issues/199 (as well as downstream issues in my svelte-frappe-charts wrapper library).

I tried to explain why this is happening here. Allow me to summarize:

• Users who install this dependency and consume it the "modern way", via installing and importing it (as described in the README):

  import { Chart } from 'frappe-charts';

• By importing from frappe-charts (not a specific file like .esm.js), we are allowing our bundler to resolve what frappe-charts means.
• Generally bundlers mostly align with Node's module resolution algorithm. Some have more options. Here's webpack's.
• This means that Node will reach into frappe-charts, inspect its package.json and hopefully resolve to some entry file specified there. Luckily frappe-charts specifies this.
• The error happens because some users, who are bundling JS for the browser, correctly set browser as the target in their bundler. This resolves to the .iife.js file currently.
• IIFE files do not export anything / cannot be consumed in those environments. This is why we are seeing this error.

Users can probably get around this issue in their bundler with some Regex gymastics / explicitly telling frappe-charts to resolve to not the browser version. Or they can do what the README says and manually specify the path to the .esm.js.

The user shouldn't have to do either of these. Also, how are libraries which consume frappe-charts meant to import it? (we believe they should be agnostic and let the bundler decide).

This PR tells Rollup to produce a UMD-style bundle, and sets that as the browser entry point.

📄 You can read more about IIFE vs UMD here.

Screenshots/GIFs:

• N/A

Steps To Test:

• One good test would be to run npm run build, grab the .umd. output file, stick it in an HTML file and open in a browser and ensure that window.frappe.Chart is still available and works as expected.
• I will put together a repo where we can test both import setups and ensure this is fixed.

TODOs:

• We may want to update our build dependencies, especially rollup and associated plugins. They have made massive improvements since the version we are using now.
• I didn't upload any of the built dist files, since I assumed that they get built before release. They are in git though, so let me know if you want me to push them.

[scmmishra]

Thanks a lot @himynameisdave I really appreciate your help on this. I'll test this PR over the weekend and release it if all works fine

[scmmishra]

This looks great! I've merged this and made a release. Thanks a lot for your contribution!

[GrosSacASac]

Nice

[barredterra]

@himynameisdave this is one of the best PR descriptions i've ever seen. Thanks for making the effort and let's hope others will take it as an example.