RFC: `wrangler pull <name>` (and alternatives)

When developers use Workers, they’re commonly onboarded by creating a new Worker in the dashboard itself (by clicking on the “Create a Service” button). The browser-based editor is pretty good, it even has autocomplete, and the sheer efficiency of going from code to production in seconds is honestly amazing. Indeed, some folks use the dashboard editor as their primary development experience.

However, there comes a time when they want to graduate to a more traditional development experience; using their own editor, splitting code up into modules, using third party dependencies from npm, and so on. Right now, they can achieve this by creating a new project (with wrangler init <name>), then copying over the script contents from the dashboard editor to created index.ts/index.js, then further copying over environment variables and other bindings into wrangler.toml. (iiuc, it’s the vars/bindings part that’s actually annoying to copy off since it’s laborious and spread out in the dashboard.)

The proposal here is to implement a command (tentatively wrangler pull <name>, but we can bikeshed that) that will automate the above steps. It will take the name of the project, and then it will create a new project in the current directory, and then it will copy over the contents of the script to the new project, as well as populate wrangler.toml with vars/bindings.

Some notes that come to mind here -

• We should not be able to run this command that was previously published with wrangler, or any other tooling. It has to have been a worker created in the dashboard. Otherwise we stand to confuse the user with multiple sources of the worker.
• We should also not be able to run this command inside an existing project, since we could corrupt the project. We can workaround this, but we have to be careful.
• As an alternative, we could also have a “download as project” button in the dashboard that creates a zip file on-the-fly of a project that includes this worker. This option is nice because they don’t have to have previously installed wrangler, it’ll come bundled with dependencies, and we don’t don’t risk corrupting an exisiting project.
• Another alternative is to simply implement a command that can download only environment variables and bindings to be copy pasted into wrangler.toml. This would be useful in other scenarios too (like when vars have been edited in the dashboard and folks want to sync it to their project before doing a wrangler publish)

This is an open topic, we’re not sure yet of the shape of the solution, and are even trying to understand the problem itself, but please feel free to contribute your thoughts and ideas.

[IgorMinar]

Thanks for the update @JacobMGEvans!

[JacobMGEvans]

This is meant to be a follow up for public transparency in planning and discussions pertaining to this happening internally and will be followed up with a spec (which I would be willing to share if people are interested).

What I had in mind was that wrangler init already has very nice DX for generating projects and customizing them to developer’s needs via interactive prompts that impact the output.

In regards to this and based on additional internal discussions, particularly addressing my concerns around anything resembling source control or source management. I agree that the wrangler init is a good place for this to live, alternatively wrangler generate might have potential, however, wrangler init does have features that can be utilized to augment to project being pulled from Cloudflare Dashboard.

I think it would be awesome if we could leverage this by enabling developers to scaffolding projects as they can today and then populating the index.js/index.ts and wrangler.toml with content pulled from an existing deployed worker (presumably created via the dash).

This highlights another good point mentioned internally in regards to agnostic of source control & storage while providing the DX of local Cloudflare tooling like Wrangler and potentially improving the user ecosystem with options like TypeScript, GitHub initialization (could consider adding others).

Cc: @IgorMinar @lrapoport-cf