@uppy/companion-client: fix body/url on upload-success

[Murderlon]

Fixes #4915
Fixes #4909

Not the cleanest fix, but not sure how do it otherwise. Couple of problems:

• Using tus/transloadit only returns a url back from Companion
• Using xhr-upload also returns response and bytesUploaded. Inside response there is responseText, status, headers.
• xhr-upload has options getResponseData, getResponseError, and responseUrlFieldName to extract data for local files, these options are not used for responses from Companion as they are handled inside companion-client. Those options where introduced for people who want to convert XML to JSON (can't believe we support that 🙈). Funnily enough, those people with XML were never able to use Companion as Companion expects the response to be JSON before sending it over websockets.
• It's impossible to type this correctly for upload-success because companion-client has no knowledge of that. Nor can we type it properly internally.

So since these options we don't assume the response and where to find the upload URL, you can extract it / point to it. How do we do it in for Companion uploads then? Well we either guess on the client of guess inside companion. Currently Companion never sends the upload URL back:

uppy/packages/@uppy/companion/src/server/Uploader.js

Lines 645 to 648 in 3c0140a

	return {
	url: null,
	extraData: { response: getRespObj(response), bytesUploaded },
	}

But it does for tus/S3. Since Companion is responsible for sending back the upload url for other uploaders I decided to guess inside Companion rather than on the client.

---

What's the ideal fix? In 4.0 I think we should remove all these extraction options for xhr-upload and force people to return JSON with a url property. Realistically, if you run your own server you need to create a new endpoint for Uppy anyway, so why make your life difficult with XML? Or by returning a key different from url? I think we can easily enforce that.

Then ideally upload-success returns consistently, so not all kinds of different data for different uploaders. Not sure how that's possible without a deep dive.

[github-actions]

Diff output files

diff --git a/packages/@uppy/companion-client/lib/RequestClient.js b/packages/@uppy/companion-client/lib/RequestClient.js
index 8277e2f..2687682 100644
--- a/packages/@uppy/companion-client/lib/RequestClient.js
+++ b/packages/@uppy/companion-client/lib/RequestClient.js
@@ -376,9 +376,18 @@ async function _awaitRemoteFileUpload2(_ref4) {
                         break;
                       }
                       case "success": {
-                        var _socketAbortControlle2;
+                        var _payload$response, _payload$response$sta, _payload$response2, _socketAbortControlle2;
+                        const text = (_payload$response = payload.response) == null
+                          ? void 0
+                          : _payload$response.responseText;
                         this.uppy.emit("upload-success", this.uppy.getFile(file.id), {
                           uploadURL: payload.url,
+                          status: (_payload$response$sta = (_payload$response2 = payload.response) == null
+                              ? void 0
+                              : _payload$response2.status) != null
+                            ? _payload$response$sta
+                            : 200,
+                          body: text ? JSON.parse(text) : undefined,
                         });
                         (_socketAbortControlle2 = socketAbortController) == null || _socketAbortControlle2.abort == null
                           || _socketAbortControlle2.abort();

[orban]

Let us know how we can support. Would love to get this merged as its currently a blocker for us.

[Murderlon]

I think we'll have it released before Friday :)