Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version Packages #289

Merged
merged 1 commit into from
Jan 24, 2022
Merged

Version Packages #289

merged 1 commit into from
Jan 24, 2022

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Jan 24, 2022

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

[email protected]

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.

@threepointone threepointone merged commit 5b7f46b into main Jan 24, 2022
@threepointone threepointone deleted the changeset-release/main branch January 24, 2022 22:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant