Skip to content
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions features/draft/vendor/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# Draft vendor features

This directory is for features proposed by a browser vendor, to support the
Comment thread
foolip marked this conversation as resolved.
Outdated
early use of web-features before there is a published web-features ID, and a
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't publish these anywhere we still can't reference them from e.g. standards positions without recreating all the build infrastructure to know what are valid definitions.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you expect to reference these in standards positions, we can publish somewhere. How about a JSON file on GitHub pages that's updated for every commit to this repo?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I expect you to reference them in standards positions (requests) :p

But yes, publishing them separately to the main ids would be fine for me.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, I wasn't sure how you plan to reference web-features in https://github.com/mozilla/standards-positions. If you add it to the template, then allowing proposed/* IDs there would make sense.

way to transition from draft to published feature IDs.

A draft vendor feature goes through these stages:

- A bot creates a `.yml` file in this directory, with enough information for a
maintainer of web-features to follow up and act on. An `explainer` or `spec`
URL and a vendor-specific URL like `chromestatus` is recommended.
Comment thread
ddbeck marked this conversation as resolved.
Outdated
- A web-features maintainer creates a real feature entry and replaces the draft
feature with a pointer to that feature.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to have a stub/example file showing a mapping from a completed draft to a real feature ID.

Or we could have a JSON file showing former vendor draft paths (this would be nicer for us, to have the folder contain only un-minted features, but would require vendors to do a little more than not overwrite an existing file).

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been resolved below. After the live review session with Philip, I was brought around to the idea that the resolution of a draft can and should happen in-place, rather than deleting or moving the files. While this is less convenient for me personally as a maintainer, it's less complex for the bots that are going to commit this stuff (e.g., the process for creating a draft file is, more or less, "don't clobber an existing file").

- References to the draft feature in vendor tools or source code are updated to
point to the final features.

Write access for bots can be granted by web-features maintainers, and should
only be used to create files in this directory.
11 changes: 9 additions & 2 deletions index.ts
Original file line number Diff line number Diff line change
Expand Up @@ -45,10 +45,17 @@ function* yamlEntries(root: string): Generator<[string, any]> {
// The feature identifier/key is the filename without extension.
const { name: key } = path.parse(fp);
const pathParts = fp.split(path.sep);
const isDraft = pathParts.includes('draft');
const isSpec = isDraft && pathParts.includes('spec');
const isVendor = isDraft && pathParts.includes('vendor');

if (isVendor) {
continue;
}

// Assert ID uniqueness
for (const [pool, map] of Object.entries(uniqueIdMaps)) {
if (!pathParts.includes("spec") && pathParts.includes(pool)) {
if (!isSpec && pathParts.includes(pool)) {
const otherFile: string | undefined = map.get(key);
if (otherFile) {
throw new Error(`ID collision between ${fp} and ${otherFile}`);
Expand All @@ -68,7 +75,7 @@ function* yamlEntries(root: string): Generator<[string, any]> {
Object.assign(data, dist);
}

if (pathParts.includes('draft')) {
if (isDraft) {
data[draft] = true;
}

Expand Down
3 changes: 3 additions & 0 deletions scripts/dist.ts
Original file line number Diff line number Diff line change
Expand Up @@ -410,6 +410,9 @@ const tagsToFeatures: Map<string, Feature[]> = (() => {
* mistakes, such as `.yaml` files.
*/
function isDistOrDistable(path: string): boolean {
if (path.startsWith("features/draft/vendor/")) {
return false;
}
if (path.endsWith(".yaml.dist") || path.endsWith(".yaml")) {
throw new Error(
`YAML files must use .yml extension; ${path} has invalid extension`,
Expand Down