avoid polyfill fetch and promise

[sibelius]

Polyfills should be in user land

https://github.com/microsoftgraph/msgraph-sdk-javascript/blob/dev/src/GraphRequest.ts#L2

can we remove those and let the user polyfill them?

[muthurathinam]

@sibelius
Is this suggestion is for the browser environments(polyfills will add more weight to the js files) ? or is this something more specific about a certain advantage ?
883188

[JSteunou]

I second @sibelius

libraries should document requirements, but let users add polyfills if they need it, not force it.

[muthurathinam]

Correct me if I am wrong, is this removal of polyfill is for the convenience of the developers to include their own choice of polyfills ?

Lets say we do want the users to include the polyfill by documenting them, in such cases

• Developers should be aware of all the usages of the library to include the correct polyfill which support everything that is being used by the library.
• Novice developers have to stretch their brains to understand about the dependencies and to include this library.

To overcome these issues in browser environment, we do ship set of two different outputted js files one with polyfills and another without polyfills(which enforces developers to include certain polyfills).

@sibelius @JSteunou Your thoughts.?

[JSteunou]

I think that's a good choice that satisfies everyone. I also noticed "main": "lib/src/index.js" in the package.json, so using a builder like webpack should include only what's necessary.

👍

[JSteunou]

Buuuuuuut it does not work because of https://github.com/microsoftgraph/msgraph-sdk-javascript/blob/dev/lib/src/GraphRequest.js#L3

So I'm in favour of #122 because usually, webpack users do know what they do, and know when and how include polyfills.

I prefer when the build with polyfills is the exception rather than the build without.

[sibelius]

You can throw an error if polyfill was not included

[muthurathinam]

By with and without polyfills I meant these two files #1 and #2.

@JSteunou This particular change will be a breaking change. So some good, supporting explanation and reference to some legitimate good practices document would be nice to take better decision.

[JSteunou]

@muthurathinam I could use those files, if I was using <script> directly. But I'm building a complex app and using webpack as a builder. Builders rely on the main entry in the package.json by default. I could work around that by importing the file without the polyfills, but I would lose possible tree shaking, nice developer help and link thanks to .ts, etc.

That's a workaround, but that's not a nice workaround. Like I said, I prefer when the without polyfill is the standard, and the with polyfill is the exception, rather the opposite. And I think it's the way JavaScript works nowadays, so please jump on board :)

[muthurathinam]

@JSteunou Thank you for the explanation. I cannot take this up as of now. If you got time to get it done first, raise a pull request, am happy to review.

[JSteunou]

I think the PR you need is #122 from @sibelius (which need some modification to still produce a file with polyfill at build step)

[muthurathinam]

I have already requested changes in that pull request. Please make those changes.