fix: add loose auto complete to string literals where applicable

[janglad]

What kind of change does this PR introduce?

Add "loose autocomplete" toWeakPasswordReasons, AMREntry.method, Factor.factor_type, SignInWithIdTokenCredentials.provider and AuthError.code

What is the current behavior?

The above types define possible string literal values, which is great, but they're unioned with string. As a regular "literal" | string just ends up as a string this foregoes the benefit of defining the literals in the first place.

What is the new behavior?

TypeScript still allows any possible string as a valid value (notice no error on the "not in there"), but now the predefined literals show up as hints. This is done by using "literal" | string & {}. While this seems hacky, it's something that works and something the TS team test against meaning they won't "fix" it in future releases.

Currently these hints aren't shown as the type just ends up as a simple string.

Additional context

I believe this can be quite helpful for people when trying to handle errors etc. I know string & {} might look somewhat weird for maintainers, if preferable I can create a LooseAutocomplete<T> or something and wrap them in there but this seemed cleaner.

[janglad]

@J0 just checking in if you could have a look at this 🙏. Maybe this change is unwanted but either way it should be a relatively quick review and it would make my life a tiny bit nicer 😄

[J0]

@janglad Thanks for the PR - could we trouble you to point us to the relevant TypeScript docs for this (if any)?

[janglad]

@janglad Thanks for the PR - could we trouble you to point us to the relevant TypeScript docs for this (if any)?

I'm sadly not aware of any official documentation for this. It it is however something that's used in quite a few big libraries (like the types for React). FWIW TS tests agains Definitely Typed and very rarely does breaking changes, I would personally not worry that this breaks in the future.

[J0]

Thank you!

[janglad]

Yay, thanks!