Conversation
This avoids the warnings currently seen on the GitHub Actions, and migrates to an up-to-date node to match what the actions themselves use.
This also moves ajv-cli@5 and ajv-formats@2 to be dev dependencies in package.json, rather than duplicating the manual install from ci.yml. It also notably currently _does not_ add any new inactive proposals to features.json; it merely will update inactive proposals that already are tracked in features.json. This could easily be changed in the future, but to avoid a much larger diff to features.json, they are currently omitted.
This means features.json now provides a full machine-readable copy of the proposals.
1cfa420 to
f4495cb
Compare
|
(Force pushed just to rebase past the conflict.) |
There was a problem hiding this comment.
The commit message and comments/documentations should be clear that the keeping-up-to-date part only applies to proposal phases, not engine support.
As for which proposals to show, see my comment below; I think it's still worth curating this a bit; this page doesn't have the same purpose as the wasm proposals repo itself.
| ...readmeProposals, | ||
| ...parseFixedPhaseFile(readProposalsFile('finished-proposals.md'), 5), | ||
| ...parseFixedPhaseFile( | ||
| readProposalsFile('inactive-proposals.md'), |
There was a problem hiding this comment.
This is sort of pre-existing but I'm not sure it's valuable to have inactive proposals. By definition nobody is working on them, and having information won't be useful to developers. I think when I originally made this page the bar was that we don't show anything that doesn't have an implementation, because this page targets developers who might want to target wasm. The scope has expanded some but I'm still not convinced that there's any value in showing proposals with nobody working on them and/or no implementations.
Deprecated proposals would be the exception there, so maybe we make some kind of carveout for that, but I think all the others would be just noise. (or maybe we leave deprecated proposals out too, just to avoid encouraging anyone to use them).
There was a problem hiding this comment.
From my point-of-view, I really just want to be able to find all WASM proposals without having to (potentially in multiple places) parse the Markdown files myself — the webpage itself is actually not really my main concern, the JSON file itself is.
The current (main) features.json seems to include all active proposals, plus inactive-but-implemented ones. The fixup commit I've just pushed filters the two places that render things based on features.json down to the that.
This branch has not been deployed
3 participants
This adds a GitHub Actions workflow, similar to what https://github.com/tc39/dataset does, to keep features.json up-to-date.