Test for outdated spec URLs that aren't in w3c/browser-specs#10681
Test for outdated spec URLs that aren't in w3c/browser-specs#10681
Conversation
github-actions
bot
added
dependencies
I merged that PR and so this PR passes now. We now only use specs listed by w3c/browser-specs (minus the temporal allow list introduced in this PR). |
ddbeck
left a comment
ddbeck
left a comment
There was a problem hiding this comment.
Thank you, Florian! A couple of ideas for you in line comments.
More broadly, it's probably not optimal for us to introduce a lot of standalone linting like this, lest we traverse the whole tree a dozen times, which is rather slow. But that shouldn't stop us now. That said, the next time we want to add something like this, we should give some thought to walking the tree once and, at each feature, dispatching to individual checks.
| 'https://wicg.github.io/controls-list/', | ||
| 'https://w3c.github.io/webrtc-extensions/', | ||
| 'https://w3c.github.io/setImmediate/', | ||
| 'https://datatracker.ietf.org/doc/html/rfc2397', |
There was a problem hiding this comment.
Most of these will no longer be exceptions if w3c/browser-specs#280 is fixed.
Thanks Daniel! I think I addressed your comments. Thanks for the great guidance here :)
Yeah, I totally agree. I think it is a bit unfortunate that the test outputs all of the files and even marks them as passing and then at the end another walk takes places and might tell you "oops, nope, I found more and this is actually wrong". So, yes, a general purpose traverse would be cool and then some of the current lints could maybe find their way into mocha based tests, too. |
| 'https://www.w3.org/TR/xpath-31/', | ||
| 'https://www.w3.org/TR/xslt-30/', |
|
|
||
| const specsExceptions = [ | ||
| 'https://wicg.github.io/controls-list/', | ||
| 'https://w3c.github.io/setImmediate/', |
* Bump version to v3.3.6 * Add release note for #10646 * Add release note for #10581 * Add release note for #10685 * Add release note for #10691 * Add release note for #6957 * Add release note for #10721 * Add release note for #10695 * Add release note for #9821 * Add release note for #10681 * Add release note for #10725 * Add stats * Add release date * Wordsmith
3 participants
We need to keep our specification URLs current to always provide the recommended and most up-to-date spec_urls as specified by w3c/browser-specs.
Therefore we should check all of our spec_urls against the w3c/browser-spec repository. The repo includes almost all of the BCD spec hosts but a few are missing still and so I've added a temporal allow list.
This PR fails because in main BCD doesn't use the recommend spec for ECMAScript right now. #10615 fixes that.
This adds a dev dependency to w3c/browser-specs. Sometimes, when dependabot asks us to update to a new version of browser-specs, it might fail the build because there a recommended spec from browser-specs has changed. Just like it is the case now with ECMAScript. So the idea is that this will add a mechanism that keeps spec urls up to date and relevant.
(I've never written a mocha test for BCD, please take it apart. Edit: I'm not happy with the error message, so maybe we can improve that if the overall approach of this PR makes sense.)