cloudflare / workers-sdk

⛅️ Home to Wrangler, the CLI for Cloudflare Workers®
https://developers.cloudflare.com/workers/
Apache License 2.0
2.69k stars 702 forks source link

🚀 Feature Request: `wrangler pages dev --remote` #3505

Open F0rce opened 1 year ago

F0rce commented 1 year ago

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 the cf-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

buckett commented 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.

buckett commented 1 year ago

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.

baer commented 1 year ago

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.

jadbox commented 1 year ago

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.

jerimiahwelch commented 1 year ago

+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.

Markloev commented 11 months ago

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'

ctarmor commented 8 months ago

I am suddenly facing issue. It's still broken.

wrangler pages dev ./build/client --remote

--remote it's not a valid parameter:

image

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.

image

Has anyone resolved this ??

jakemoves commented 5 months ago

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 😁

niklauslee commented 4 months ago

I really need this feature, it works for workers, why not for pages?

glassworks-projects commented 4 months ago

+1 :/

bjankord commented 4 months ago

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

dvrfluxchat commented 3 months ago

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)

Noitidart commented 1 month ago

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.