Open F0rce opened 1 year ago
I had a similar issue where I was trying to debug some caching behaviour of fetch()
in a pages function and allowing remote development would have simplified this.
Using the dashboard playground as outlined on: https://developers.cloudflare.com/workers/learning/playground/#using-the-playground allows quick iterating on code that runs on CF servers and may be helpful in some cases.
For context, this is the file that runs wrangler pages dev
. There is quite a lot of hard-coded local-only stuff in it like forcing the D1 database to local-${d1}
. Unfortunately, I think this will be quite a lift.
I'd like to bump up visibility as it's a blocker for multiple teams. We could not test our app against production via wrangler pages dev --remote
as we had assumed. Without this, we cannot even test a page worker fix against production data.
+1 for this feature. We often see different responses to local and CDN sub-requests. We don't have a simple way to preview or debug these differences.
Also in need of a solution here, but specifically for me, I need a way to access remote Cloudflare KV/R2 after running 'wrangler pages dev'
I am suddenly facing issue. It's still broken.
wrangler pages dev ./build/client --remote
--remote
it's not a valid parameter:
I've spent 4-5 hours trying to get this to work but no luck. I've gone thought all the remix / cloudfare docs and still can't access my remote D1 instance.
Wrangler CLI does work fine accessing remotely:
wrangler D1 execute job_listing_db --command "select * from listing"
trying accessing from remix always gets the error, table not found, becasue it's trying to run locally against a non-existent local D1.
Has anyone resolved this ??
I'm suffering working locally, trying to figure out how to access a file uploaded to local storage via R2. If I could run wrangler pages dev --remove
and point it to my actual R2 bucket I wouldn't have to figure it out 😁
I really need this feature, it works for workers, why not for pages?
+1 :/
Was surprised to find out the --remote
flag works for CF Workers but not for CF Pages. Was working on a CF Pages app that has a function that reads data from a KV store. Running locally, it was undefined, but when I deployed the app, it works.
Was hoping I could run something like wrangler pages dev --remote
to develop locally but still be able to access the data from the KV store.
Edit: I understand the idea trying to prevent people from messing up their "production" KV store when running their app locally.
After playing around with this some more, I think the ideal state would be allowing developers the choice to decide (via CLI flags or wrangler.toml) which KV store we wanted to bind to when running the wrangler pages dev
command.
For example, you could bind to the preview KV store, or if you really wanted to, you could bind to your "production" KV store, or bind to a local file based KV store. This would make it easier to debug KV prod data issues instead of forcing to always use a local file based KV store when running wrangler pages dev
Commenting for visibility. This is really a deal breaker, as i want to test against remote data on my local machine. Is there any hack people have figured out to achieve this?
I am trying to use the KV binding.
This is currently possible for workers but not for pages. https://developers.cloudflare.com/workers/testing/local-development/#develop-using-remote-resources-and-bindings
I could not find a fix so I am using upstash redis for KV and delayed execution(which was achievable with durable object alarms)
I also had this need. I work with a small team, and right now we are having to share our local state folder around, which is getting messy. Running npx wrangler pages dev --remote
says main entry point not found.
Describe the solution
Hi everyone,
When developing frontend applications using Cloudflare pages, we use some of the
CF-
headers to validate some requests (for example, getting thecf-ipcountry
to show the user a recommendation for switching languages).There are a few more headers that are relevant to our logic, but at the moment we are unable to test these headers and the logic behind them without first deploying to pages, tailing the logs and then making some improvements to the code.
Maybe it's as simple as "copying" the logic from
wrangler dev --remote
to pages, but I haven't looked at it directly, nor do I know the exact logic behind wrangler.Thanks in advance and appreciate all the work, David