Skip to content
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.

Sign up for GitHub

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

Add initial feature support definition #40

Merged
merged 8 commits into from
Feb 15, 2023
Merged

Add initial feature support definition #40

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
2e4b186
Add intial constituent feature data
ddbeck Jan 13, 2023
9ae1238
Enforce formatting on YAML files
ddbeck Jan 13, 2023
f297f3d
Merge branch 'main' into constituent-features
ddbeck Feb 3, 2023
04c1d22
Use underscores for constituent features
ddbeck Feb 3, 2023
4ad53d0
Merge branch 'main' into constituent-features
ddbeck Feb 15, 2023
832c458
Flatten constituent features
ddbeck Feb 15, 2023
309208d
Fix typo
ddbeck Feb 15, 2023
4b93376
Rename "constituent_features" to "compat_features"
ddbeck Feb 15, 2023
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
4 changes: 4 additions & 0 deletions .prettierignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
/*

# Opt-in the YAML files only (at least for now)
!/feature-group-definitions/*.yml
1 change: 1 addition & 0 deletions .prettierrc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
{}
15 changes: 15 additions & 0 deletions feature-group-definitions/cascade-layers.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,2 +1,17 @@
spec: https://drafts.csswg.org/css-cascade-5/#layering
caniuse: css-cascade-layers
constituentFeatures:
- source: "@mdn/browser-compat-data"
query: css.at-rules.layer
- source: "@mdn/browser-compat-data"
query: css.at-rules.import.layer
- source: "@mdn/browser-compat-data"
query: api.CSSImportRule.layerName
- source: "@mdn/browser-compat-data"
query: api.CSSLayerBlockRule
- source: "@mdn/browser-compat-data"
query: api.CSSLayerBlockRule.name
- source: "@mdn/browser-compat-data"
query: api.CSSLayerStatementRule
- source: "@mdn/browser-compat-data"
query: api.CSSLayerStatementRule.nameList
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder if we can't separate mappings between different data sources and make this one BCD specific for simplicty? Something like:

bcdFeatures:
  - css.at-rules.layer
  - css.at-rules.import.layer
  - api.CSSImportRule.layerName
  - api.CSSLayerBlockRule
  - api.CSSLayerBlockRule.name
  - api.CSSLayerStatementRule
  - api.CSSLayerStatementRule.nameList

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think that's a possibility, though I have a concern about what it implies about the relationship between the feature and its constituents. For instance, if I migrate something here like the mockup's array.json and we split them up by source, we might end up with something like:

localFeatures:
  - array-relative-indexing
  - array-grouping
bcdFeatures:
  - javascript.builtins.Array
  - javascript.builtins.Array.Array
  - javascript.builtins.Array.concat
  - …

If we structure the data like this, I'm concerned that it:

  • Obfuscates the fact that only localFeatures plus bcdFeatures describes a complete thing (i.e., neither key alone describes the feature)
  • Makes for a bad contribution experience, where it puts the focus on data sources rather than the feature description (put another way: if BCD lacks some data to accurately characterize a feature and its support, that's a problem to fix in BCD, not a constraint on what the feature is)

That said, I recognize that the form I've presented is verbose and repetitious (though I'm not 100% certain if that's your concern, exactly). I think it would be OK to be terser, use short hands, and set defaults (or some combination thereof). Some ideas along these lines:

constituents:  # less words
- query: css.at-rules.layer
  # implicit default for `source: "@mdn/browser-compat-data"`?
- bcd:css.at-rules.layer  # use some sort of source:identifier string notation?
- bcd://css.at-rules.layer  # webbier-looking version the previous line?
- css.at-rules.layer  # assume that dotted paths are BCD?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@foolip I've switched the name of the new key to underscores and merged in the usage stats from main. I was wondering if you had any more thoughts on the mapping situation. Happy to move forward with any reasonable suggestion (of which they're all reasonable, including separating the data sources). But I wanted to give you another opportunity to chime in before I moved forward on migrating more data out of the mockup.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I thought I had replied here last week, but no.

Unless we have another data source in mind that we could use for computing web-feature statuses I think we should simplify and optimize for the case that all constituent features are from BCD.

But I think that if I'm right about this it will quickly become evident just by trying to maintain the data, so I don't need to get my way if your hunch is different.

19 changes: 17 additions & 2 deletions index.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,22 @@ import YAML from 'yaml';

interface FeatureData {
spec: string,
caniuse?: string
caniuse?: string,
constituentFeatures?: Array<{source: string, query: string}>
}

// Some FeatureData keys aren't (and may never) be ready for publishing.
// They're not part of the public schema (yet).
// They'll be removed.
const omittables = [
"constituentFeatures"
]

function scrub(data: FeatureData) {
for (const key of omittables) {
delete data[key];
}
return data;
}

const filePaths = new fdir()
Expand All @@ -23,7 +38,7 @@ for (const fp of filePaths) {

const src = fs.readFileSync(fp, { encoding: 'utf-8'});
const data = YAML.parse(src);
features[key] = data;
features[key] = scrub(data);
}

export default features;
6 changes: 4 additions & 2 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,12 @@
"main": "index.ts",
"scripts": {
"build": "ts-node scripts/build.ts",
"test": "npm run test:caniuse -- --quiet && npm run test:schema && npm run test:specs",
"test": "npm run test:caniuse -- --quiet && npm run test:schema && npm run test:specs && npm run format",
"test:caniuse": "ts-node scripts/caniuse.ts",
"test:schema": "ts-node scripts/schema.ts",
"test:specs": "ts-node scripts/specs.ts"
"test:specs": "ts-node scripts/specs.ts",
"test:format": "prettier --check .",
"format": "npx prettier --write ."
},
"devDependencies": {
"@types/caniuse-lite": "^1.0.1",
Expand Down