add module upload support

[jgodson]

PR to upstream the changes from Shopify#16 that adds support for uploading scripts that use the module syntax.

It builds upon the changes started here

Closes #794

[github-actions]

changelog detected ✅

[sodabrew]

Awesome! Don't say I never shopped on Shopify :)

Since I'm just working on a round-trip use case over in #1007, I'll note that DownloadWorker also needs to handle module-format workers. There is only an example for a plain worker at https://api.cloudflare.com/#worker-script-download-worker

$ curl <auth headers> https://api.cloudflare.com/client/v4/accounts/<accountid>/workers/scripts/<scriptname>

Content-Type: application/json
[rest of the headers]

self.addEventListener... [rest of the script]

The same API call for a Module-format worker returns multipart that would need to be parsed. What should happen if there are multiple parts?

$ curl <auth headers> https://api.cloudflare.com/client/v4/accounts/<accountid>/workers/scripts/<scriptname>

Content-Type: multipart/form-data; boundary=abcdefg
[rest of the headers]

--abcdefg
Content-Disposition: form-data; name="worker.js"

export default {
  fetch(request) {
    return new Response("Hello world")
  },
};
--abcdefg--

The return type from cloudflare.DownloadWorker is

type WorkerScriptResponse struct {
        Response
        WorkerScript `json:"result"`
}

But the code for the method actually does this:

...
        var r WorkerScriptResponse
        r.Script = string(res)
        r.Success = true
        return r, nil
}

I'm not sure I follow what's going on there with how Go is inferring and passing types from that method (limitations of my Go knowledge)

[sodabrew]

Got it, the struct fields are being promoted from nested structs

type WorkerScriptResponse struct {
        Response
        WorkerScript `json:"result"`
}

type WorkerScript struct {
        WorkerMetaData
        Script     string `json:"script"`
        UsageModel string `json:"usage_model,omitempty"`
}

type WorkerMetaData struct {
        ID         string    `json:"id,omitempty"`
        ETAG       string    `json:"etag,omitempty"`
        Size       int       `json:"size,omitempty"`
        CreatedOn  time.Time `json:"created_on,omitempty"`
        ModifiedOn time.Time `json:"modified_on,omitempty"`
}

Thing is, most of these fields are not set by the DownloadWorker response!

So back to the issue at hand: is it possible for a DownloadWorker to respond with multiple module files? If so, what's the best way to represent that as a Go structure? (I'm thinking map[string]WorkerScript where the key is the module file name)

[jgodson]

Is it possible for a DownloadWorker to respond with multiple module files?

That is an excellent question. I'm not really sure as I haven't tried that/needed to do that yet.

I believe that the upload functionality at least is covered here, so if download could be implemented separately, this should be good to go as is (at least it has been working for us so far).

[jacobbednarz]

@jgodson i'm hoping to getting to review/test this in the coming days. are you able to address the CHANGELOG entry so there is one less thing to do before we merge?

[jacobbednarz]

thanks for your patience here @jgodson. the PR looks great and my (basic) testing of this internally is looking great.

[sodabrew]

@jacobbednarz Glad to see this land! Where are you at in terms of thinking about how to solve for DownloadWorker to return something sensible when a module worker is fetched? #1010 (comment)

[jacobbednarz]

haven't really dug into the issues with DownloadWorker and i'd have to chat with the team about how they intend to solve it for multiple workers.

[github-actions]

This functionality has been released in v0.47.0.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!