Add --compatibility-date, --compatibility-flags, --latest cli arguments to dev and publish#215
Add --compatibility-date, --compatibility-flags, --latest cli arguments to dev and publish#215threepointone merged 3 commits intomainfrom
--compatibility-date, --compatibility-flags, --latest cli arguments to dev and publish#215Conversation
🦋 Changeset detectedLatest commit: 3b89849 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
…rguments to `dev` and `publish` Closes #193. This PR adds cli fields for 2 existing configuration fields: `--compatibility-date`, `--compatibility-flags` matching `compatibility_date` and `compatibility_flags` respectively. It also adds a cli arg `--latest` which is shorthand for `--compatibility_date <today>`. It follows the rules from the linked issue - - A cli arg for adding a compatibility data, e.g `--compatibility_date 2022-01-05` - A shorthand `--latest` that sets `compatibility_date` to today's date. Usage of this flag logs a warning. - `latest` is NOT a config field in `wrangler.toml`. - In `dev`, when a compatibility date is not available in either `wrangler.toml` or as a cli arg, then we default to `--latest`, and log a warning. - In `publish` we error if a compatibility date is not available in either `wrangler.toml` or as a cli arg. Usage of `--latest` logs a warning. - We also accept compatibility flags via the cli, e.g: `--compatibility-flags formdata_parser_supports_files` I haven't added validation for the actual values of these args, I'll get to that next week when I work on the config validation work. The wording of the messages/errors are also up for discussion. I'm happy to keep this PR alive until we get it right.
threepointone
force-pushed
the
compat-date
branch
from
bbdcdf4 to
3d4b86c
Compare
I think logging a warning for |
| type: "array", | ||
| alias: "compatibility-flag", | ||
| }) | ||
| .option("latest", { |
There was a problem hiding this comment.
Should we error if compatibility-date and latest are both used?
Should we log a warning if there is a compatibility-date set in config and is being overridden by --latest?
There was a problem hiding this comment.
I... hrmm. I'd push back against the error; the use case is the commands been generated by some other tooling, or literally just inside an npm script, and you're overriding it manually to try the latest runtime version. Would be annoying if an error blocked you then. We have the warning anyway, and it's an annoying one that you can't miss.
| "⚠️ Using the latest version of the Workers runtime. To silence this warning, please choose a specific version of the runtime with --compatibility-date, or add a compatibility_date to your wrangler.toml.\n" | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
I agree with @petebacondarwin that the warning during dev is unnecessary. Removing it.
| type: "array", | ||
| alias: "compatibility-flag", | ||
| }) | ||
| .option("latest", { |
There was a problem hiding this comment.
I... hrmm. I'd push back against the error; the use case is the commands been generated by some other tooling, or literally just inside an npm script, and you're overriding it manually to try the latest runtime version. Would be annoying if an error blocked you then. We have the warning anyway, and it's an annoying one that you can't miss.
We introduced some bugs in recent PRs: - In #196, we broke being able to pass an entrypoint directly to the cli. In this PR, I just reverted that fix. I'll reopen #78 and we'll tackle it again later. (cc @jgentes) - In #215, we broke being able to publish a script by just passing `--latest` or `--compatibility-data` in the cli. This PR fixes that by reading the correct argument when choosing whether to publish. - In #247, we broke how we made requests by passing headers to requests. This PR reverts the changes made in `cfetch/internal.ts`. (cc @petebacondarwin) - In #244, we broke `dev` and it would immediately crash. This PR fixes the reference in `dev.tsx` that was breaking. (cc @petebacondarwin)
We introduced some bugs in recent PRs: - In #196, we broke being able to pass an entrypoint directly to the cli. In this PR, I just reverted that fix. I'll reopen #78 and we'll tackle it again later. (cc @jgentes) - In #215, we broke being able to publish a script by just passing `--latest` or `--compatibility-data` in the cli. This PR fixes that by reading the correct argument when choosing whether to publish. - In #247, we broke how we made requests by passing headers to requests. This PR reverts the changes made in `cfetch/internal.ts`. (cc @petebacondarwin) - In #244, we broke `dev` and it would immediately crash. This PR fixes the reference in `dev.tsx` that was breaking. (cc @petebacondarwin)
3 participants
Closes #193.
This PR adds cli fields for 2 existing configuration fields:
--compatibility-date,--compatibility-flagsmatchingcompatibility_dateandcompatibility_flagsrespectively. It also adds a cli arg--latestwhich is shorthand for--compatibility_date <today>. It follows the rules from the linked issue ---compatibility_date 2022-01-05--latestthat setscompatibility_dateto today's date. Usage of this flag logs a warning.latestis NOT a config field inwrangler.toml.dev, when a compatibility date is not available in eitherwrangler.tomlor as a cli arg, then we default to--latest.publishwe error if a compatibility date is not available in eitherwrangler.tomlor as a cli arg. Usage of--latestlogs a warning.--compatibility-flags formdata_parser_supports_filesI haven't added validation for the actual values of these args, I'll get to that next week when I work on the config validation work. The wording of the messages/errors are also up for discussion. I'm happy to keep this PR alive until we get it right.