This migrates one bucket of files using some amount of Flow typing to mark them
as TypeScript instead. The remaining type errors are fixed in subsequent
commits.
Turns out a lot of the typescript warnings about improper warnings were correct. TypeScript appears to be pulling in two copies of the js-sdk when we do this, which can lead to type conflicts (or worse: the wrong code entirely). We fix this at the webpack level by explicitly importing from `src`, but some alternative build structures have broken tests because of this - jest ends up pulling in the "wrong" js-sdk, breaking things.
Just a minor thing that is bothersome. Renaming classes and functions is a bit more of an impact than is worth right now, so have settled for littering TODO comments all over the place.
Turns out that setUserWidget() wasn't updated to take a real WidgetType, but the code in ScalarMessaging thought it did. This leads to integration managers trying to add sticker widgets with an object `type` rather than a string `type`, which doesn't work.
This updates other code paths which call into the various widget classes to use WidgetType more often. The actual code path for fixing widgets is resolved in WidgetUtils for the setUserWidget function body.
This is needed because `require()` means something different in webpack - it ends up importing the module as something we didn't expect (and is occasionally async)
This avoids a visual glitch where the Integration Manager portal would briefly
appear, but then be replaced by a smaller Terms dialog when there's something to
agree to.
To resolve this minimal code churn, this cheats a bit and customises the size of
the terms dialog to match the IM portal modal when terms are shown for IM
purposes.
Fixes https://github.com/vector-im/riot-web/issues/10386
before passing to js-sdk. We continue to use the full URL for the
calls done by matrix-react-sdk, but the standard terms API called
by the js-sdk lives on the standard _matrix path. This means we
don't support running IMs on a non-root path, but it's the only
realistic way of transitioning to _matrix paths since configs in
the wild contain bits of the API path.
Once we've fully transitioned to _matrix URLs, we can give people
a grace period to update their configs, then use the rest url as
a regular base url.
This moves the responsibility of creating a URL to open from the button (and other components) to the integrations manager dialog itself.
By doing this, we also cut down on scalar API calls because we don't pick up on account information until the user opens the dialog.
This mostly helps with people migrating between integration managers where their old scalar token may no longer be valid. This also solves the problem of people switching between scalar and scalar-staging in the wild.
Signed-off-by: Travis Ralston <travpc@gmail.com>
Handle error getting the scalar token and check for non-success status codes in the response handler (because apparently browser-request doesn't consider that an error).
