[Feature Request] - Refactor types under internal package to a public location

[trentrosenbaum]

Is your feature request related to a problem? Please describe.

I have implemented an auth service in my cli that orchestrates the use of the MSAL Go public.Client to provide an interactive/browser based user journey. My problem is experienced when I am expanding my tests around this auth service and I want to mock out the public.Client to create different tests cases.

I am able to introduce an interface that the client satisfies and then mock it, but when I go to implement the return types of public.Account and public.AuthResult, (as an example) I find that I cannot create the appropriate type, (for example accesstokens.IDToken RawToken) because the struct fields are from accesstokens or base packages located under the internal package.

• apps/internal/oauth/ops/accesstokens
• apps/internal/base

The type public.AuthResult is an alias to base.AuthResult and so I cannot set it types when they reference accesstokens.IDToken.

Describe the solution you'd like

Would the project consider moving these and related types to another package that is available to consuming code? This would allow me to mock out the client and then unit test my services.

Additional context

I am not sure if there is a reason why the code has been structured in this way and so looking just to understand more. I understand the use of internal to limit what is publicly available to consumers, but it feels like these internal types are more publicly facing because of there exposure through public.AuthResult etc.

[bgavrilMS]

@chlowell - is this a potential breaking change / something we'd want to take for GA?

[chlowell]

We can do this any time, it's non-breaking. It isn't strictly necessary, but I think we should export IDToken and any other internal types that are transitively exposed by public types. That exposure makes the fields of internal types publicly accessible and thus a possible source of breaking changes.

@trentrosenbaum you can use that fact to set IDToken fields on an AuthResult. I take it you tried something like this:

ar := confidential.AuthResult{
	// build error: accesstokens is internal, can't reference its types
	IDToken: accesstokens.IDToken{RawToken: "..."},
}

However, creating an AuthResult implicitly creates a zero value IDToken whose fields you can reference:

// this compiles
ar := confidential.AuthResult{}
ar.IDToken.RawToken = "..."

Are you able to complete your mock with this approach?