cloudflare-docs

cloudflare-docs copied to clipboard

WIP/Concept

https://kian-wrangler-configuration.cloudflare-docs-github.pages.dev/workers/wrangler/configuration/

Todo:

• [x] WASM/Blob/Text - file bundling
• [x] Workers Sites
• [x] Proxy support

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	Secret	Commit	Filename
-	Generic High Entropy Secret	3b2a8c69b717ca778d233ec70a91933b3d6d8f75	config.toml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

@threepointone Hi Sunil - if you get a chance, I'd appreciate your thoughts on this PR.

From a technical standpoint, I think it'd be good to get an opinion from someone who actively works on Wrangler.

I haven't documented the assets key or the JSX related stuff since I'm not entirely familiar with those and they're not in the existing documentation - but I'll be happy with releasing this documentation as long as we're not losing any 'functionality' compared to the old documentation & adding those in at a later date.

FWIW I still need to do a bundling JS example - hence the // do stuff haha

FWIW I still need to do a bundling JS example - hence the // do stuff haha

Cool, so I will assume this is in WIP status? Do you think you could draft the PR then?

FWIW I still need to do a bundling JS example - hence the // do stuff haha

Cool, so I will assume this is in WIP status? Do you think you could draft the PR then?

Done - it's just that 1 part to go but I'm not 100% on how it works so I can't write it without trying it myself, which I'll do tonight.

@KianNH do you mind rebasing/resolving conflicts when you get a sec?

With D1 now being merged into main, is it worth documenting those bindings?

Edit: looks like we also need to add migrations, send_metrics and keep_vars

keep_vars is documented on main 🙈 edit: IMO smaller PRs are easier to get merged - I recommend documenting d1 bindings on a separate PR

I'll rely on the 'this PR is older than that feature' excuse.

IMO smaller PRs are easier to get merged - I recommend documenting d1 bindings on a separate PR

I'll hold off on D1 for now since there's also no documentation to refer people to - i.e KV/DO/R2/etc have their own documentation that people can read if they don't know what the binding is.