feat(cloudflare): Enable update of the wrangler file

[JPeer264]

(closes #1148)

This PR will update the wrangler config automagically. The wrangler config can exist in .toml, .json and .jsonc (source) that is why I added smol-toml (BSD-3) and jsonc-parser (MIT).

These are the new steps:

1. Wrangler config does not exist: We create a minimal jsonc config with the minimum required keys (also jsonc is recommended for new projects)
   • On top we instruct that the name and the main line has to be changed
2. Wrangler config does exist in either format: It adds Sentry specifics
   • For .toml we add a copy paste snippet

For now we add:

• nodejs_als instead of nodejs_compat to keep the bundle size smaller, and it is not yet required
• compatibility_date to the date of creation (suggested by the Cloudflare docs)
• And our required version_metadata

Drawbacks

Toml parsers are not quite popular and are not really feature complete, that is why toml files would loose all comments, once we update them (another option would be to not support .toml at all and give only a hint) (the toml parser has been removed)

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against cc48ea9

[Lms24]

Nice!

Toml parsers are not quite popular and are not really feature complete, that is why toml files would loose all comments, once we update them (another option would be to not support .toml at all and give only a hint)

If we discard user-created comments, I'd rather tend towards showing copy/paste-able instructions in the console. We have a showCopyPasteInstructions and makeCodeSnippet helpers that should make this fairly user friendly.

Logaf-L though, so happy to leave the decision up to you!

[Lms24]

l/m: We could try to reuse our existing parseJsonC helper and avoid adding another dependency. I'll admit, the parsing strategy is a "bit" hacky, so if there are any obvious drawbacks, feel free to continue using jsonc-parser.

[JPeer264]

There are 3 drawbacks which I found on the quick implementation, where I'm not 100% certain if it is worth the effort to fix - since jsonc-parser does have almost 30m weekly downloads and is maintained by Microsoft.

---

Drawback #1. We apparently remove whitespaces

---

Drawback #2: Comments are sometimes moved somewhere else

---

Drawback #3: The complexity of the code gets a little bit more, since we have to deal with merging AST (e.g. existing array fields or existing objects), which was plain objects before see mergeValue

[Lms24]

more than enough reasons to use jsonc-parser. thanks for checking!

[JPeer264]

If we discard user-created comments, I'd rather tend towards showing copy/paste-able instructions in the console. We have a showCopyPasteInstructions and makeCodeSnippet helpers that should make this fairly user friendly.

I removed the toml parser, since it seems really a little odd when the comments get removed. In the future we can always add it as feature in case there is demand. Cloudflare itself is also leaning more to jsonc anyways.

[JPeer264]

It seems that the jsonc-parser has some problems with esbuild, as stated here. The workaround works great for the Cloudflare workers-sdk, which we can't use, since fossilize doesn't allow extra fields.

I now removed the external dependencies and stick with our drawbacks, they are not that harmful. However, one test is skipped, where the comments are at the wrong place.