evaluate whether we still need commonjs support

[baywet]

Since we originally stood up this library the ecosystem has moved a lot:

• nodejs supports ESM, and all supported versions have them enabled by default now
• major community projects have moved to ESM only, including some in our build infrastructure (see #1041 where we can't upgrade to chai 5 because we still have commonjs based tests)
• we've established that the sub modules we have (fluent API, sub-namespaces for models...) can only be consumed in ESM (when the generated client is published as its own package) when working on msgraph-sdk-typescript.
• we're still on the 2.X branch of node-fetch because 3.X moved to ESM

IMHO we should remove commonjs support after testing our main scenarios (SPFx, TeamsFX....) and BEFORE the GA so people don't end up in confusing variants + configuration misalignment issues.

[baywet]

@gavinbarron @musale I'd love your input on this one when you have a couple of minutes.

[musale]

I agree with removing cjs support all together. You have made valid points to remove it. ESM has more desirable benefits like tree-shaking which helps developers bundle smaller sizes of the sdk in their apps. In the core https://github.com/microsoftgraph/msgraph-sdk-typescript-core repo, this has already been done. In mgt, we removed it and directed using module syntax in the browser when loading mgt from the cdn https://github.com/microsoftgraph/microsoft-graph-toolkit/releases/tag/v4.0.0.

[baywet]

@sebastienlevert I think we have an agreement on the engineering side for this one. Especially since it's blocking other work. Any opposition to removing common is support here?

[sebastienlevert]

No. We should definitely drop it at this point.

[baywet]

Thanks for your input. @musale please proceed as part of your existing PR.

[sebastienlevert]

Decision is to drop commonjs support.

[baywet]

Wait, we still need to do some work to remove it