Reduce bundle size for @azure/identity with better tree shaking support

[MichielVrins]

Packages impacted by this PR

• "@azure/identity"

Issues associated with this PR

None

Describe the problem that is addressed by this PR

This PR reduces the bundle size of this library by making it more tree shakable. Before this PR the following code would pull in 851KB of unminified js from @azure/identity. This PR brings that down to 753KB. Other authentication flows should see similar results.

import { ClientCertificateCredential } from "./credentials/clientCertificateCredential.js";

export const credential = new ClientCertificateCredential("tenant-id", "client-id", {
  certificatePath: "assets/fake-cert.pem",
});

Two fixes that are addressed in this PR are.

1. Import required module's exported functions or constants directly instead of using import * (851kb to 790kb)
2. Splitting of auth flows into exported functions and inject the client context instead of having 1 monolithic client which is inherently not tree shakable. (790kb -> 753kb)

Below are screenshots of a before and after bundle for only ClientCertificateCredential.

Future improvements

Taking a look at the resulting bundles I can still see some easy wins to reduce the bundle size further. One that immediately stands out to me, is that jsonwebtoken pulls in quite some js. E.g. jsonwebtoken pulls in semver which accounts for almost 10% of the whole bundle size (61.3KB) and some more. Sadly this needs to be fixed upstream in the msal libraries which are not in this monorepo.

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?

The msalClient could have been trimmed down to only having a context and the auth flow specific code could have been moved to it's respective flows. Since many of the functions here follow a similar pattern they can easily get out of sync and get harder to maintain. I suspect that that's why they were structured like this in the first place, and that's why I kept it like this.

Are there test cases added in this PR? (If not, why?)

No, tests only had to get plumbed up correctly again. No new logic was added.

Provide a list of related PRs (if any)

None

Command used to generate this PR:**(Applicable only to SDK release request PRs)

None

Checklists

• Added impacted package name to the issue description
• Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
• Added a changelog (if necessary)

[github-actions]

Thank you for your contribution @MichielVrins! We will review the pull request and get back to you soon.

[MichielVrins]

@microsoft-github-policy-service agree