One of the goals of the rewrite to v2 is to encourage contributions from outside cloudflare (hence the choice of typescript, for example). We should write out a CONTRIBUTING.md that explains how to set up the development environment, and how t contribute patches back to the repo.

(This depends on me first writing a decent number of tests and fixing the types, of course)

As mentioned at https://blog.cloudflare.com/catching-up-with-workers-kv/, it should be possible to use getWithMetadata to get key metadata (including the content-type).

I'm not sure if wrangler is populating the KV entry metadata yet. I thought I remember seeing a PR for it, but can't find it to see if it was merged yet or not.

Currently the kv:bulk tool will only upload values that are strings. This is different from the KV web back end when you can upload json values. The behaviour seems to come from cloudflare::endpoints::workerskv::write_bulk::KeyValuePair. Would changing the type of KeyValuePair.value from String to json::JsonValue be sufficient to fix this? I'm not sure if this library is used for more than wrangler or not so it might be cumbersome to make API changes but it is a cloudflare library.

Or if there is some workaround that I am unaware of, this request could be quickly closed.

I'm a little confused, cache bypass seems to be set for all requests that have a cookie beginning with "wordpress".

A lot of my pages on my site (activewords.com) have wordpress_test_cookie set. So these pages are never cached.

Surly the code should allow cookie wordpress_test_cookie to be cached?

💡 Feature request

A way to locally debug the code

Overview and problem statement

In every reference to the word "debug" in the documentation, i can only see ways to debug with logs.
i find myself adding a log after a log, while i just need a breakpoint.

we are developing using wrangler dev with a result of a typescript build with webpack.

Hi ✋ Whilist using kv-asset-handler I've seen some points of improvement worth to share. Would be happy to discuss on each, making sub-issues or going with some PRs to address.

Unnecessary files published inside npm package

Checking unpkg files like tsconfig.json or .github are published which increase install size. You may use files field in package.json to whitelist only dist (or also src)

Legacy dist

I can understand that cloudflare workers support (at least partial) of ES6 so we may keep things like await syntax which may help reduce final worker size (and probably more v8 optimization by using modern syntax). Using tsc, you may use ESNext but also careful not using unsupported features like optional chaining. Or using a modern tool like siroc (/cc @danielroe) or directly esbuild. (benefit of using siroc would be to also generate .mjs output that allows final compiler to do better tree-shaking, publishing public types.

Using full version of mime

mime has a lite entry (25 kB vs 9 kB) which is containing all of standard mimes. This can significantly reduce bundle size. You may import from mime/lite

Suggestion

• It would be great to have a dockerized version of this program that is self-contained
• include an option to for build-required files (i.e. cache the template requirements in the image so they don't have to be downloaded everytime you call build
• include node version option

There are several instances throughout this project where HTTP headers are set in an inconsistent case.
For example, here's a place where Cache-Control is set lowercase. Here's a place where it's not.

These inconsistencies should be addressed. My suggestion is to set them per their casing as presented on MDN.
Cache-Control instead of cache-control, ETag instead of etag, etc.

This issue tracks the implementation of wrangler tail.

Usage

• as before, you can run wrangler tail inside a project and it'll start showing live logs for the worker defined in that project.
• additionally, you can pass a script name directly to it, like wrangler tail <name> and it'll tail the worker from your account with that name.
  • Consequently, you won't need to clone the worker's repo, install all dependencies, all just to tail the worker anymore. You should now be able to run npx wrangler tail <name> from anywhere.
• in v2, we only log in the json format, and don't support all the filters yet. We will fix this soon to add pretty mode, and all the filter flags: --status, --header, --method, --sampling-rate, --search.

💡 Feature request

Describe the feature

Currently, there is no way to test scheduled jobs, since we can't fire a scheduled during development. I suggest adding support of "cron triggers testing" for wrangler dev or wrangler preview, which speeds up the development and testing.

Possible methods of triggering a cron job during development:

• For wrangler dev, wrangler creates a special route (path) during development, and developers can trigger a job by sending a request to the route, eg: GET http://127.0.0.1:8787/__crons/:cronExpression
• For wrangler preview, a Test Triggers tab is available for developers to trigger a cron job.

Describe the alternatives

The current work around for this issue is to simply deploy the worker to production.
Or add the code I want to test to the fetch event handler, which is really inconvenient:

addEventListener('scheduled', (event) => {
  event.waitUntil(scheduledJob(event))
});
addEventListener('fetch', (event) => {
  event.respondWith(scheduledJob(event))
})
const scheduledJob = (event) => {
  // Job
}

Thanks.

I have an Angular app. A standard Angular app consists of an index.html and several js bundle files.
In my Workers Sites app, the general Cache-Control setting I want to use for all assets is max-age=86400. There is 1 exception to this - the index.html. I want to use no-cache for that. However, differentiating the index.html from other assets has proven rather tricky.

Here is my code:

let isIndex = false;
response = await getAssetFromKV(event, { mapRequestToAsset: request =>
{
    //KV is case-sensitive. We will only publish files with names in lower-case, so force the request URL path to be lower-case.
    //https://community.cloudflare.com/t/workers-sites-missing-images/121633/9
    const defaultAssetKey = serveSinglePageApp(request);
    const defaultAssetKeyUrl = new URL(defaultAssetKey.url);
    defaultAssetKeyUrl.pathname = defaultAssetKeyUrl.pathname.toLowerCase();

    isIndex = defaultAssetKeyUrl.pathname.endsWith("index.html");

    return new Request(defaultAssetKeyUrl.toString(), defaultAssetKey);
}, cacheControl : { edgeTTL: 31536000 } }); //We cannot set browserTTL in here at this time because we don't know at this point if the requested asset will end up being index.html or something else.

if (isIndex) response.headers.set("Cache-Control", "no-cache");
else response.headers.set("Cache-Control", "max-age=86400");

As-is, that works and does what I need, but I feel it could be better.

Here's what I mean. I am aware that options has browserTTL. However, at the point where options need to be specified, I cannot determine whether the asset being processed is going to end up being index.html or something else. That's the job of the serveSinglePageApp function. As you can see in my code, I came up with a workaround.

Ultimately, I would like to be able to set options.browserTTL to make things look clean, but I'm not sure how that is possible given the way this is currently designed.

Thoughts?

This issue tracks the implemention/inclusion of wasm friendly features for wrangler v2. It's not been tested at all, and I expect it might require some changes. Of note, a deliverable for this feature is for workers-rs to Just Work.

When it comes to typescript we have to manually link the wrangler.toml with TypeScript. For me this might look like this:

interface Env {
  MyKVVariable: KVNamespace
}

Some other libraries generate these types for you, so you can't mess up by removing it from the config, but TypeScript still thinks it's there. I think this would be a cool feature for us too!

We're considering deprecating the wrangler preview command. It's not as powerful as wrangler dev, and it usually lags in features that we're implementing in workers. That said, we recognise that it makes development on Workers accessible to folks, so we can't simply rip it away without a strong story. Perhaps we should make sure we have great development stories with tools like codesandbox / stackblitz / codepen / etc (and perhaps directly in our docs too). This issue looks to collect feedback and describe alternative strategies for when we do actually deprecate it.

🐛 Bug Report

Environment

• operating system: macOS
• output of rustc -V:rustc 1.33.0 (2aa4c46cf 2019-02-28)
• output of node -v: v12.16.1
• output of wrangler -V: 👷 ✨ wrangler 1.9.2
• contents of wrangler.toml: type: webpack - using a standard Gatsby template

Steps to reproduce

• Run wrangler publish with bypassCache: true or set the edgeTTL to a specific value and send a new build
• Access the build

What did you expect to see?

• The new version of the build being served

What did you see instead?

• The older version of the build (have to manually empty the browser cache, on both desktop and mobile - Chrome latest version, to see the new version)

Basically, what's happening is that when I send a new build using the cache options available, instead of getting a fresh version of the build (it's a Gatsby static website), I see the older version, and have to keep cleaning the cache on the client side to see the new content. What I'd expect is that when I send a new version of the static content, it'll serve that new version, and cache it (say for 24h or 1 week).

I'd like to ask if there's any additional step that I didn't take, or any extra documentation on caching that would help me solve this issue, maybe a manual purge on the worker or something? I'd be glad to share more information if needed.

Thank you!

💡 Feature request

Overview and problem statement

We are seeing exceptions in production that we are struggling to diagnose. We have followed all of the debugging tips here, including wrapping our handler in a try/catch and firing off error logs but I still have no visibility into the errors which suggests to me the exceptions are being thrown outside of the handler. Unfortunately, we don't know how to replicate these errors and we're not seeing them in our non-prod environments.

What I would like to do now is pull logs from production, but when trying to use wrangler tail I get the following error.

$ npx wrangler tail --env master | grep "exception" > exceptions.txt
🦚  Setting up log streaming from Worker script "master". Using ports 8080 and 8081.
⠲   This may take a few seconds...
Error: ⚠️  Code 10057: workers.api.error.too_much_traffic_for_live_tailing
🕵️  See documentation

What I'd like to propose is a couple of improvements:

1. Document whether there is any mitigation option available folks who encounter this issue
2. Provide some way to pre-filter logs before they enter the tail pipe

I think many services would seek to provide a sampled tail when traffic is too high, and this might be a great solution, but only if it removed duplicate log entries. If I lost unique (and valuable) exception logs as a result of sampling then that would be equally frustrating.

I understand this request is probably unreasonably difficult, but as it stands today I don't really have any other options.

Basic example

Provide a --sample flag to indicate that we're happy to only receive a sample of the logs in the given environment.

$ npx wrangler tail --sample

This is the parent issue tracking the implementation of wrangler dev.

Usage

In it's simplest form, you can write a worker, say at index.js, and run: wrangler dev index.js, and -

• it'll immediately start up a local server at http://localhost:8787/
• in "watch" mode on by default
• You'll also see a bar in your terminal with hotkeys for some added functionality-
  • B to open a browser
  • D to open devtools (relevant issue: TODO)
  • S to start a tunnel to the internet, and copies a url to your clipboard that you can share with anyone (relevant issue: TODO)
  • X (or Q) to quit
• You'll note that you do NOT have to specify an account id. wrangler dev will infer your account id automatically (unless you provide it in your wrangler.toml or via CF_ACCOUNT_ID)
• Notably, we aim to provide a default experience that's immediately useful, so you shouldn't have to setup a bundler/compiler for most usecases. So, you can use modules from npm, create separate modules, use react (todo: --jsx <reference> for other libraries), use typescript, and it should all Just Work.
  • This is currently powered by esbuild, but we may/may not change that in the future. We're not planning on exposing all the configuration options, or even the plugin interface yet. We have ideas for how we'll do this, and will share details when we have some clarity.
    • A notable miss is being able to 'polyfill' node's builtins (like crypto, path, etc) to provide compatibility with a number of libraries in the ecosystem. We'll do this soon (and perhaps for Deno libs as well?)
    • Similarly, we should probably also enable http imports for module.
  • That said, you're not blocked on setting up your own build pipeline, you can indeed use any tools you like (like, webpack, parcel, etc), and point wrangler to the output as an entry point. We'll document this properly soon.
  • We'd like to move away from custom build configuration, instead passing it directly in the cli, so you should be able to do, for example wrangler dev script.js -- webpack --watch (and similarly for publish) Custom builds implemented in #149
• wrangler dev will automatically infer whether you're using the service-worker format or the newer ES modules format.
• This doesn't currently support wasm, workers-rs well, and we'll fix that soon. Done.
• And finally, we haven't implemented all the other flags for dev yet. --port works, but we have yet to do --ip, --host, --local-protocol, --upstream-protocol.

Summary

(Glossary: Asset's hashed pathname is the path key that is used in KV to match the corresponding stored asset.
ASSET_MANIFEST maps the normal pathname to hashed pathname, like 404.html => 404.eeab4c0347.html.)

In a case when asset requested by its hashed pathname (e.g. 404.eeab4c0347.html) rather than the normal one (e.g. 404.html), the worker could handle such (special) request and do return the correct asset as if handling normal request. However, in such case, the worker unexpectedly ignores cache options, thus it would not cache the response and would always fetch asset from KV every time it handles such hashed pathname request.

Expected Result

When asset requested by hashed pathname, the worker should return 404, or return the asset and apply cache options properly.

Actual Result

The worker does respond with the requested asset, but cache options fail, and worker always fetches asset from KV.

Steps to Reproduce

It could be reproduced just with the default template.

wrangler generate --site hello-world-site
cd .\hello-world-site\
wrangler publish

With following default cache options:
https://github.com/cloudflare/kv-asset-handler/blob/3228cd78de1f4f61d74cecb13a3b19054d67d501/src/index.ts#L56-L60

When we request asset in normal path manner (e.g. img/200-wrangler-ferris.gif), the worker will retrieve the asset (response) from Cache (if cache exists) and return. For example:

$ curl -s -D - -o /dev/null https://hello-world-site.***.workers.dev/img/200-wrangler-
ferris.gif | egrep "HTTP/|content-type:|etag:|cf-cache-status:|age:"
HTTP/2 200
content-type: image/gif
age: 20
etag: img/200-wrangler-ferris.8f4194bc08.gif
cf-cache-status: HIT

We can tell it is a cached response from that the age and cf-cache-status header appears.

And the etag header in the response reveals the asset's hashed pathname. So, literally everyone could easily find an asset's hashed pathname in this way.

However, if we try to directly use hashed pathname requesting asset, (take img/200-wrangler-ferris.8f4194bc08.gif for example here)

$ curl -s -D - -o /dev/null https://hello-world-site.***.workers.dev/img/200-wrangler-ferris.8f4194bc08.gif | egrep "HTTP/|content-type:|etag:|cf-cache-status:|age:"
HTTP/2 200
content-type: image/gif

The response is not retrieved from the Cache, but rather constructed with asset object freshly retrieved from the KV, and the absence of age and cf-cache-status header could support this statement.

Causes

https://github.com/cloudflare/kv-asset-handler/blob/3228cd78de1f4f61d74cecb13a3b19054d67d501/src/index.ts#L126-L134

Hashed pathname (e.g. 200-wrangler-ferris.8f4194bc08.gif) is not in ASSET_MANIFEST (what in ASSET_MANIFEST is 200-wrangler-ferris.gif), thus shouldEdgeCache is false when handling hashed pathname (pathKey) request, and worker would not fetch response from Cache, instead, would try to fetch asset from KV:

https://github.com/cloudflare/kv-asset-handler/blob/3228cd78de1f4f61d74cecb13a3b19054d67d501/src/index.ts#L166-L169
https://github.com/cloudflare/kv-asset-handler/blob/3228cd78de1f4f61d74cecb13a3b19054d67d501/src/index.ts#L209-L213

But since the hashed pathname (pathKey) is real, the asset could do be successfully retrieved from KV. However, due to shouldEdgeCache is false, the following cache control operation is skipped:

https://github.com/cloudflare/kv-asset-handler/blob/3228cd78de1f4f61d74cecb13a3b19054d67d501/src/index.ts#L215-L226

I am afraid that this may be a potentially vulnerable bug or defeat which could be exploited maliciously, since KV I/O is "preciously" billing and limited.

Question - at the moment the behaviour seems to be if any comment is added to the site, the edge cache is purged. If a site has a high volume of comments that are filtered as spam, will those also trigger the cache purge?

I'm wondering if there's a way to check if the comment is flagged as spam before doing the cache purge. It seems that there's a comment_approved variable that should return "spam" that might work?

https://developer.wordpress.org/reference/hooks/comment_post/

This tracks the implementation of Durable Objects in wrangler v2.

It currently doesn't exist, but soon will. We expect to match wrangler v1's implementation, and potentially also detect if the exports don't match (whether fewer, or more).

More details soon.

💡 Feature request

Support for workers which, when configured and "published" via wrangler, appear as "Disabled" in the UI.

Overview and problem statement

I would like to include additional configuration for workers which operate on routes that have a very broad scope, such as mysite.com/api/* to manage specific routes which I know do not need to invoke not just the current worker, but any worker, in order to reduce unnecessary worker invocations.

Basic example

Currently, I must do this manually, or automate it via some light scripting. Although it's not that bad to manage this via the API, it'd be much nicer to get this type of feature in front of users so that it can reduce worker invocations.

It would be great to set this in my wrangler.toml file somehow, perhaps as an "environment".

wrangler.toml

type = "webpack"
account_id = "..."
zone_id = "..."
name = "all-i-want-for-christmas-is-fetch-event-bubbling"
route = "mysite.com/api/*"

[env.disabled]
type = "disabled"
routes = ["mysite.com/api/.well-known/jwks", "mysite.com/api/customers/thatoneguy/*", "mysite.com/api/externalthing/*" ]

$: wrangler publish -e disabled

Or however you want to do it. The important part is that this information about disabled routes is contained next to the rest of my worker's source code. The bits where workers aren't running is just as important as where they do run!

• This is a bug in the service-worker-mock package and is tracked here: zackargyle/service-workers#135
• This bug only affects kv-asset-handler when invoking response.body.cancel()

I have a few question about Cache-Control behavior:

1. Will kv-asset-handler respect header set after getAssetFromKV?

const response = await getAssetFromKV(event,{}); // Passed in an empty object as an option
response.headers.set('cache-control', 'public, max-age=3600');

Will the file be cached at Cloudflare Edge for 2 days (default cache behavior) or an hour?

If the answer is an hour (which means the later set cache-control is used),

const response = await getAssetFromKV(event,{}); // Passed in an empty object as an option
response.headers.set('cache-control', 'public, max-age=3600, s-max-age=4800');

Will the file be cached ar Cloudflare Edge for 80 minutes or an hour?

2. How to use options.cacheControl as a function?

When trying to find the answer of the above question, I went through the code and found this:

https://github.com/cloudflare/kv-asset-handler/blob/eb120a4b789282e4c44ff8b95e2dd2e220b83e6d/src/index.ts#L129-L135

It is never mentioned in the README. Should it be considered not to use in production (Not mentioned in docs thus the behavior might change in the future)?

3. Should s-max-age be implemented for caches.put inside kv-asset-handler?

https://github.com/cloudflare/kv-asset-handler/blob/eb120a4b789282e4c44ff8b95e2dd2e220b83e6d/src/index.ts#L177-L181

It seems that putting cache into Cloudflare Edge is done by kv-asset-handler (Might answer question 1? The headers set later won't be respected?). As far as I know, Cloudflare Edge respect both max-age & s-max-age, and the s-max-age takes higher priority (max-age for browser, s-max-age for CDN).

With s-max-age is used, there might be no need for those Cache-Control manipulation strategy:

https://github.com/cloudflare/kv-asset-handler/blob/eb120a4b789282e4c44ff8b95e2dd2e220b83e6d/src/index.ts#L184-L189

(Is it trying to override edgeTtl with browserTtl, and then even delete Cache-Control if the file shouldn't be cached by browser?)

💡 Feature request

It would be nice to filter by "Cron trigger" and "HTTP request", just like the web interface.

Currently the pretty log format doesn't indicate that it's a Cron Trigger either:

[2021-10-08 11:20:17] [SIN] [Ok] POST https://example.com/api/license
[2021-10-08 11:20:11] [?] [Ok] */20 * * * *

My app, every.org, is using Cloudflare Workers to host our static bundle. We have URLs for nonprofits, looking like every.org/<nonprofit slug>, and slugs can currently have periods in them. so for instance, the url for the popular nonprofit Vote.org is every.org/vote.org.

However we found out that because cloudflare tries to read mime types to determine if it should tack on index.html or not, and because the mime package decides that a .org extension ought to be a MIME type of application/vnd.lotus-organizer, it decides that this isn't actually supposed to be a page, searches for an asset with that name, can't find it and then hard crashes our website.

We're working around this by not using the serveSinglePageApp helper since it's so simple to implement ourselves, but would be nice if the default either didn't presume so much or was clearer that you could bork your site based on your URL scheme. Thanks!

This is the parent issue tracking the implementation of wrangler publish.

Usage

In it's simplest form, you can write a worker, say at index.js, and run: wrangler publish index.js --name myscriptname, and -

• it'll 'bundle' your script into a single file, and publish it to myscriptname.<your subdomain>.workers.dev
• Much like wrangler dev, we aim to provide a default experience that's immediately useful, so you shouldn't have to setup a bundler/compiler for most usecases. So, you can use modules from npm, create separate modules, use react (todo: --jsx <reference> for other libraries), use typescript, and it should all Just Work. (more details on the tracking issue for wrangler dev)
• Much like wrangler dev, wrangler publish will also automatically infer whether your script is in the service-worker format or the newer ES modules format.
• You can publish to your own domain/zone with wrangler publish <script> --name <name> --zone somedomain.com --route "somedomain.com/path/*"
  • You'll note that you can pass a domain directly to zone, instead of a zone_id. wrangler publish should work with both forms of configuration.

Reported in cloudflare/wrangler-legacy#980

if a path does not have a recognized extension, we currently assume that it is pointing to an html file, so hostname.ext/foo is automatically converted to hostname.ext/foo/index.html. This is rather specific to the expectations of a few select static site generators (esp hugo), however, it messes with files that have no extension (in the above issue, files under **/.well-known/*), and with other static site generators such as jekyll, who assume that hostname.ext/foo should be evaluated as hostname.ext/foo.html.

we need to update the default fetch from kv logic to:

• try the original path first before trying other variations
• try using Accept headers to evaluate mimetypes that cannot be evaluated based on extension

Depending on implementation these could be breaking changes; however if implemented properly they should be backwards compatible.

This issue tracks wrangler v2's integration with miniflare.

wrangler v2 supports "local" mode across the board.

• You can call wrangler dev ... --local, wrangler kv:* ... --local and it'll run 'locally' on your machine.
• During development (with wrangler dev), you can hit the L key and toggle between local/remote mode as you please.
• We'll integrate even deeper with miniflare soon, including but not limited to durable objects, a first class testing story, --public and more.

GitHub Pages adds access-control-allow-origin: * to all pages, so for static content hosted by Cloudflare Workers Sites, I'm guessing it should be safe to do the same.

averyharnish.com works
averyharnish.com/?twoplustwo=five works

averyharnish.com/cats works
averyharnish.com/cats?twoplustwo=four does not work

💡 Feature request

Enable public access of wrangler dev workloads.

Describe the feature

This feature request is the opposite of cloudflare/wrangler-legacy#1820 (and any other "run workers locally" requests): I love that wrangler dev runs workloads on edge servers, but it's unclear if accessing those workloads publicly is possible. Being able to use those workers at an auto-generated, public URL would be ideal.

The specific use-case: most/all of my development work is not done locally, so exposing dev workloads on localhost is incompatible with the way I work across distributed services in the cloud and across providers. Even more specifically, I'd really like to be able to more easily work on workers that are themselves webhook endpoints for other services (like e.g. Stripe).

Describe the alternatives

My current workaround is to either publish the thing to a specific subdomain and then tail the logs or, more often, to spin up something like localtunnel to use as a temporary webhooks endpoint. The first solution is much slower than I expect an equivalent wrangler dev would be. The second solution is both cumbersome and somewhat silly conceptually, since wrangler dev is already tunneling from the edge to localhost and my tunnel is sending that data right back into the public realm through yet-another-network.

Skipping that extra hop altogether and enabling publicly-accessible workloads during dev would improve my Workers workflow considerably!

It's also entirely possible that I'm mis-reading the documentation. If it's already possible to access dev workloads publicly, then consider this a feature request for updated and clarified docs.

@xtuc has a WIP PR that would add sourcemaps to anything published with wrangler. we should utilize these maps in wrangler dev. @xtuc has already implemented source maps in the devtools protocol - the source map is accessible as base64 encoded json

Possible implementations

• Implement in the runtime
  • JavaScript implementation
    • probably easier
  • C++/KJ implementation
    • possibly more performant

@xtuc would need to talk with runtime team about how we would possibly move forward with this approach. He noted a possible concern with regards to leaking meaningful stack traces in response bodies.

• Implement everything in Wrangler
  • could parse base64 sourcemap from devtools and compute accurate line numbers from lineNumber and columnNumber fields from devtools
  • alternatively could read in source map from webpack config and not worry about base64 and compute accurate line numbers from lineNumber and columnNumber fields from devtools protocol

This approach is probably the easiest but would require any new clients to also implement their own source map handling approach. My guess is that long term we probably want the runtime to support this.

wrangler v2 has partial support for Workers Sites. This issue tracks the implementation.

• We need to do some work to make sure the hashes of the files generated when saving to KV are the same as wrangler v1, and we add all the validation that wrangler v1 has. #277
• We've added the ability to specify the directory for Sites in the cli, so for example you can do wrangler dev script.js --site path/to/assets (You can still specify it in wrangler.toml, of course).
• Error if asset is over 25Mb - 87cbf75
• #282

This tracks the implementation of debugging tools for wrangler dev.

• Hit the D hotkey when developing, to open a hosted devtools at built-devtools.pages.dev
• Open chrome://inspect on chrome, or edge://inspect on edge, and follow the instructions there to open the browser devtools inspector.
• Connect vscode debugger to the inspector and debug inside your IDE directly.

Features

• See console.log(...)/console.error(...) objects in the Console tab
• Profile your workers following the steps in https://developers.cloudflare.com/workers/learning/profiling-workers
• #1315
• Support breakpoints
• Enable the Network tab, so you'll be able to see and inspect subrequests that your worker makes
• Support debugging websockets requests

kv-asset-handler interacts with cache in some unusual ways. This affects the cf-cache-status response header which may or may not be served by Cloudflare cache directly.

To Do:

• Determine if Cloudfare cache is returning a cf-cache-status on all requests
• If cf-cache-status is being set redundantly in kv-asset-handler, does the cache status value accurately describe the state of the object in cache?
• Are there benefits to setting it anyways? One benefit is that there is no obvious way to write tests without providing the header value

Originally posted by @shagamemnon in cloudflare/kv-asset-handler#133

I am currently testing something that is heavily reliant on KV and caching and metadata. And it would be great if I could switch Miniflare to switch from using an internal KV-like tool to map to a real KV namespace so we can test against an actual KV store.

I'm using this code

const data = await getAssetFromKV(event)
return new Response(data.body, data)

and I'm unable to use the cache. I keep getting MISS by checking the request in devtools

I can see that it's set to false by default
https://github.com/cloudflare/kv-asset-handler/blob/f9bb072da86ec91ae8bb3b0cd06b219e26d638c2/src/index.ts#L159
and only set to true if we use ASSET_MANIFEST
https://github.com/cloudflare/kv-asset-handler/blob/f9bb072da86ec91ae8bb3b0cd06b219e26d638c2/src/index.ts#L160-L167

Is this intended or I'm missing something?

Wrangler 2.0.0 - Project Board

This is the parent issue tracking feature implementations and deprecations for wrangler v2. We commit to be not just feature complete, but also with a solid backward compatibility plan AND a migration plan for the deprecations being made. Expect this list to grow and shrink on the journey to completion.

Features:

• #1
• #2
• #6
• #7
• #10
• #274
• #4
• #197
• #5
• #188
• #291

Deprecations

• #8
• #9
• #14

Smaller tasks

• #193
• #205
• #302
• #298
• #299
• #207
• #170
• #55
• some form of #190
• #185
• #300
• #301
• #3

This issue is for tracking details on how to migrate a project from v1 to v2. Roughly, the difference between the features that look the same, what features are deprecated and how to replace their functionality, and maybe how to take advantage of newer features.

💡 Feature request

Describe the feature

When I do MY_KV.list() from JavaScript, it returns a list of keys and metadata.

But when I do wrangler kv:key list --binding=MY_KV on the command-line, I only get the key names, and not the metadata.

It would be neat if the CLI also listed the metadata information similarly to the JS API.

Describe the alternatives

Alternatives include:

• Making the API call to GET accounts/:account_identifier/storage/kv/namespaces/:namespace_identifier/keys [source], which returns key names and metadata.
• Using a Cloudflare Worker that runs the .list(), that I can curl from the command-line 🙂

These alternatives work quite well but it would be nice to have this integrated in the main CLI tool for convenience.

Thanks!

This issue tracks how we should probably do releases.

• I'm a fan of changesets, let's do that.
  • That solves a number of process problems at once: changelogs, waiting for people to cut a release, permissions, etc
• Additionally, every commit should be published on to npm as an alpha (or some other tag). This should make experimentation a little easy too.
• Finally, it would be nice if we could publish PRs to a separate temporary registry. Open to ideas here.

cloudflare/kv-asset-handler#133, which enables etag support for all resource types hasn't been merged. When a strong etag is presented, partial responses to byte range requests are cached. However when weak etags are served, partial responses to range requests are not cached.

The resource types that will gain etag support when cloudflare/kv-asset-handler#133 is merged, and cache behavior on CF, Chromium and Safari, need to be investigated before cloudflare/kv-asset-handler#165 can be merged

Originally posted by @shagamemnon in cloudflare/kv-asset-handler#165 (comment)

For people that are not familiar with ins/outs of cloudfront it's not clear where the let asset=... line goes in the default index.js so that a react app can run.

When we pass in something like browserTTL: 0, we want to also be able to specify cache-control rules like no-cache and must-validate.

Using Wordpress, the cache is not being cleaned on a planned article.

Our articles are published also on the homepage so they are published on the category but not in the homepage. only solution, re-save the article after it has been published.

When looking into leveraging miniflare for our worker script, we noticed that the caching implemented within miniflare is different from the cache api in workers. Because miniflare leverages "http-cache-semantics" (which cloudworker also uses for its cache implementation), 429s are explicitly not cacheable. This stems from the storable call here, which is defined here. The check against understoodStatuses here and defined here will decide that a 429 is not storable and not cacheable, when the actual worker does allow caching of 429s.

Since http-cache-semantics is adhering to the RFC (and based on kornelski/http-cache-semantics#31 they aren't very open to changing which status codes are cacheable), it seems like if miniflare is going to use http-cache-semantics it might need to override the storable method?

wrangler v2 deprecates the type and webpack_config configurations, and it's overall webpack integration story.

• This has historically been a pain point both internally and externally. We haven't been able to update the webpack version (v4) because of breaking changes, and it scares away people from using wrangler in the first place.
• The other two values for type - javascript and rust don't make much sense anymore since it's really the same thing backing it. And we're going to encourage development in multiple languages (Go, python, what have you) since we want to have the best wasm support ever.
• Because we now ship esbuild, we can automatically provide support for a number of features that bundlers are typically used for: modules, jsx, typescript, etc.

TODO: as part of the effort to be backward compatible, we should have a super low-effort transition guide to moving existing webpack projects to the new wrangler (ideally, we should be able to automate it with a single command/codemod).

This issue tracks the implementation of init, and the general onboarding process.

• You can run wrangler init (or optionally wrangler init <name>, and it'll generate a wrangler.toml file where it's called with a name and compatibility_date.
• We are considering expanding the types of configuration we accept: as ideas, it could be a .ts file (so you can typecheck your configuration), a .json file or included in package.json, and so on. (TODO: an issue just for configuration)
• We are considering rethinking --generate and the overall onboarding process. We may build create-workers-app (inspired by create-react-app and other like it) to provide a better onboarding experience, but also so we can upgrade the experience without much configuration in the future.

🐛 Bug Report

I'm having an extremely strange issue where Fetch() completely ignores any custom port when actually running in the deployed Worker but from the quick editor, it works as expected.

I've gotten the Worker as simplified as much as possible to try and debug this issue. To explain the test, I have Nginx running on 443 and another application on 4567.

Steps to reproduce

addEventListener('fetch', event => {
  event.respondWith(rewriteURL(event.request))
})
 
async function rewriteURL(request) {
  let urlWithPort = new URL("https://test.file.properties:4567/download/file")
  urlWithPort.port = 9055
  //return new Response(urlWithPort) - shows the port 9055 in the URL, as it should.
  const response = await fetch(urlWithPort, request)
  return response
}

What did you expect to see?

• When I test this code from the quick editor, I get 502 (expected) because I specified port 9055 and it's using that as I told it to
• When I test this code by visiting the deployed URL, I get an Nginx 404 page (so it's completely ignoring port 9055)
• If you change urlWithPort.port to 4567 (or remove it), the quick editor will successfully return it from the application running on port 4567 (expect some JSON error about processing the request because the application expects some headers and parameters)

I'm expecting the deployed Worker to use the custom specified port when doing Fetch() just like it does on the quick editor.

--
Wrangler wasn't used to create this worker, so I didn't specify any environment. I've entirely used the online quick editor.

💡 Feature request

An ability to deploy shared worker to multiple zones (multi domain support).

Overview and problem statement

We have hundreds of domains, that need to be deployed on the same account. Our implementation is limited by worker limit and inability to re-use the worker in multiple domains.

Problem more clearly stated here: https://community.cloudflare.com/t/wrangler-deploy-to-multiple-zones-same-worker/156426/8