Skip to content

Relax early feature spec URL validation #3470

@ddbeck

Description

@ddbeck

Right now, if you want to add a feature before its specification has merged into a spec known to browser-specs, then you must add an exception to specs.ts. It's annoying. I'm proposing an alternative authoring model.

A proposal field in a .yml file would be an alias for spec that bypasses the normal spec URL validation. It would allow (almost any) parseable URL, but guidelines would require stipulate that authors must use a URL in the following order of preference:

  1. A PR against an actual spec known to browser-specs
  2. Any other PR
  3. Any other URL (e.g., an explainer)

If the proposal URL is a spec known to browser-specs then that's an error (it should be in the spec field).

On build, index.ts would rewrite proposal to spec (so it'd be transparent for consumers).

If we did this, then we'd be able to produce a watch list for features that need "permanent" spec URLs. For PR URLs, we'd be able to monitor the status of PR URLs and warn when they've closed or merged, as suggested in #3452.

Like #2647, we might check non-PR URLs for simple existence.

Metadata

Metadata

Assignees

No one assigned

    Labels

    early featuresFeature definition work for features without shipping implementationsenhancementNew feature or requesttools and infrastructureProject internal tooling, such as linters, GitHub Actions, or repo settings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions