Compatibility date warnings

[Cherry]

When you startup a new project with wrangler dev and have a compat date in the future, you often see warnings like this:

[mf:wrn] The latest compatibility date supported by the installed Cloudflare Workers Runtime is "2023-05-18",
but you've requested "2023-05-25". Falling back to "2023-05-18"...

This feels very strange to me. As a user, I had no clue there was even a concept of "supported" compatibility dates.

Advice for years when working with Workers has been to set your compat date to the day you start your project. From the docs: https://developers.cloudflare.com/workers/platform/compatibility-dates/

When you start your project, you should always set compatibility_date to the current date

And the original blog: https://blog.cloudflare.com/backwards-compatibility-in-cloudflare-workers/#introducing-compatibility-dates

A compatibility date typically starts out as the date when the Worker was first created, but can be updated from time to time.

When you do this though, you get warnings from workerd every time you start your project which is very disconcerting. Is this no longer the recommended approach? Perhaps this warning should only be presented if I have a date in the future that's unknown, AND I'm not running the latest version of workerd?

I understand cloudflare/workers-sdk#3343 exists and will "solve" this warning for C3 created projects, but I'm not sure it solves the underlying confusion around this change yet, and for any new projects that simply create manually and follow the docs.

[isaac-mcfadyen]

To add on some of our discussion on the Discord here, this might make sense in some ways - after all, if you have an old runtime on your computer and Wrangler doesn't warn, the production runtime might be newer and have breaking changes.

However, it still doesn't seem to make sense to alert when you have the latest runtime release on your computer, the same one as running in production on Cloudflare. Perhaps a check for "is this runtime version the same as production" instead of "is this date newer than the runtime date" might make sense?

[petebacondarwin]

Yes, I think we should probably move to a more nuanced logic for deciding whether to trigger this warning.

Something like, "is the date new than the one in the currently installed workerd AND is there a newer version of workerd that could be installed?"

This is the concern that we are trying to catch, where you chose a compatibility date to access some new feature but inadvertently forgot to update workerd itself to a version that supports that new feature.