One of the most common complaints is the ability for people to pass in additional arguments to the underlying MSAL library that we don't expose ourselves. Instead of us having to add support for every single parameter, we might want to give people the "keys to the kingdom" and offer a lower level experience where they get to customize everything.
We would keep our library around, but we would "scaffold" the msal code into the templates (like we did for Azure AD/B2C) in previous versions and that would enable people to customize, update and interface with msal however they deemed fit. It doesn't pose a big burden on our side, as we would still need to update the library periodically, and we don't really care if that change is on the templates or on a nuget package. The main difference here would be that customers would be responsible for keeping the JS version of the library up to date (same as with a SPA) but will gain the ability to add features as needed without waiting for us to support them.
One of the most common complaints is the ability for people to pass in additional arguments to the underlying MSAL library that we don't expose ourselves. Instead of us having to add support for every single parameter, we might want to give people the "keys to the kingdom" and offer a lower level experience where they get to customize everything.
We would keep our library around, but we would "scaffold" the msal code into the templates (like we did for Azure AD/B2C) in previous versions and that would enable people to customize, update and interface with msal however they deemed fit. It doesn't pose a big burden on our side, as we would still need to update the library periodically, and we don't really care if that change is on the templates or on a nuget package. The main difference here would be that customers would be responsible for keeping the JS version of the library up to date (same as with a SPA) but will gain the ability to add features as needed without waiting for us to support them.