-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Slightly Improve process for experimental features in wrangler #11938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…ental features are appropriately handled
|
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
| 3. **Markdown Headers**: No h1/h2/h3 headers (breaks changelog formatting) | ||
| 4. **Analytics**: If the change collects more analytics, it should be a minor even though there is no user-visible change | ||
| 5. **Dependabot**: Do not validate dependency update changesets for create-cloudflare | ||
| 6. **Experimental features**: If some experimental feature is being introduced, make sure that if the feature is part of the Wrangler CLI than it is behind an experimental flag (as described in the "Experimental Flags" section of `./packages/wrangler/CONTRIBUTING.md`). If the feature is not part of the Wrangler CLI make sure that it is disabled by default and that it can be enabled by some configuration that clearly represents the experimental nature of the feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the right job to be detecting this? The aim of this job is to check changesets, not general practices in PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I agree... I think this is ok since we validate the presence of a changeset and if someone is adding an experimental feature they should include the way to opt-in into it in the changeset, however if we prefer I can take a different approach
do you have anything in mind? like having a different CI check where Claude reviews all the changes instead of just the changeset ones?
|
|
||
| ### Integration with Cloudflare REST API | ||
|
|
||
| The [Cloudflare REST API](https://developers.cloudflare.com/api/) whenever possible should not be interacted directly with, the [Cloudflare TypeScript SDK](https://www.npmjs.com/package/cloudflare) package should be used instead. This helps maintaining the code more type safe and concise as well as preventing the usage of undocumented and unstable features that might be present in the raw REST API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@penalosa had a different view last time I checked?
…experimental features are appropriately handled simplify Claude requirement for experimental features
Fixes https://jira.cfdata.org/browse/DEVX-215
The changes here:
A picture of a cute animal (not mandatory, but encouraged)