cloudflare/workers-sdk wrangler@0.0.12

on GitHub

Patch Changes

• #292 e5d3690 Thanks @threepointone! - fix: use entrypoint specified in esbuuild's metafile as source for building the worker

  When we pass a non-js file as entry to esbuild, it generates a .js file. (which, is the whole job of esbuild, haha). So, given <source>/index.ts, it'll generate <destination>/index.js. However, when we try to 'find' the matching file to pass on as an input to creating the actual worker, we try to use the original file name inside the destination directory. At this point, the extension has changed, so it doesn't find the file, and hence we get the error that looks like ENOENT: no such file or directory, open '/var/folders/3f/fwp6mt7n13bfnkd5vl3jmh1w0000gp/T/tmp-61545-4Y5kwyNI8DGU/src/worker.ts'

  The actual path to the destination file is actually the key of the block in metafile.outputs that matches the given output.entryPoint, so this PR simply rewrites the logic to use that instead.

• #287 b63efe6 Thanks @threepointone! - fix: propagate api errors to the terminal correctly

  Any errors embedded in the response from the Cloudflare API were being lost, because fetchInternal() would throw on a non-200 response. This PR fixes that behaviour:

  • It doesn't throw on non-200 responses
  • It first gets the response text with .text() and converts it to an object with JSON.parse, so in case the api returns a non json response, we don't lose response we were sent.

  Unfortunately, because of the nature of this abstraction, we do lose the response status code and statusText, but maybe that's acceptable since we have richer error information in the payload. I considered logging the code and text to the terminal, but that may make it noisy.