Skip to content

nuance of compatibility_date behaviour.  #193

@threepointone

Description

@threepointone

Filing an issue with details of how I think compatibility_date should be enforced/nudged:

  • It should probably be a cli arg as well, eg. --compatibility_date 2022-01-05
  • We should have a shorthand --latest that sets compatibility_date to today's date. Usage of this flag should log a warning.
  • "latest" should NOT be a config in wrangler.toml.
  • In dev, when compatibility_date is not available in either wrangler.toml or as a cli arg, then we should default to --latest.
  • In publish we should error if compatibility_date is not available in either wrangler.toml or as a cli arg. Usage of --latest should log a bold warning.

I think these rules will make wrangler still be usable when hacking on something, and devs will be able to get the latest and greatest version of the runtime, but prevents breaking stuff in production unless folks go out of their way to do so.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions