Support for setLocale regardless of import order

[haydnhkim]

Previously, import order was important to use setLocale.
It had to import setLocale first, then run setLocale and import yup.

this pull request can set the locale via setLocale regardless of the import order.
This is also convenient when someone use it, and is also useful if someone need to load and set the user language asynchronously.

[ctavan]

I actually stumbled upon this exact issue about 5 minutes before you opened this PR, so I'd be really happy to see this merged ;).

However it made me think that it might be worthwhile to reconsider the singleton-nature of the yup library. Before your patch the whole locale thing was dependent of import order.

With your patch that's fixed but now we have an implicit dependency on call order which would make it really hard to reliably reconfigure locales during runtime (not sure if that's an actual use case though).

This could be mitigated by introducing instances of yup where locales are always loaded upon instance creation and remain immutable afterwards.

Again, I'm not sure if there's a real use case for this. Being independent of import order is already a huge step forward! 👏

[jquense]

Thanks!

[klis87]

@ctavan 1 use case I see is for example server side rendering. Singletons are really dangerous there as 2 requests executed at the same time could cause some race conditions - like request 2 could overwrite request 1 language which would cause mixed languages in request 1. With SSR, it is always safest to work with independent instances for each request.