(Creating the issue to document the idea somewhere following discussions with @dontcallmedom. Not sure whether we'll work on this any time soon :))
The IDL validation in spec-prod only validates the spec IDL in isolation. This prevents detection of errors such as referencing interfaces that do not exist in other specs, creating IDL that duplicates IDL defined in another spec, or even simple typos such as using bool instead of boolean.
The action could leverage the @webref/idl package to merge the spec IDL with the rest of the Web platform's IDL and validate the whole thing to report such issues.
Some notes and open questions:
Before running checks, the code will have to remove any matching IDL extract from the @webref/idl package (based on the spec's shortname)
The @webref/idl package is released once per week, so checks may validate the spec IDL with IDL extracts that are one week old. Our assumption is that this won't cause any real issue as specs often reference "stable" IDL from other specs.
Some specs define IDL that is not directly targeted at browsers and not contained in the @webref/idl package. This may make the validation report on errors that do not really exist. There should be a way to disable that validation.
We probably don't want to update the version of spec-prod every week to bump the version of the @webref/idl package. The code should rather install the latest version of the package (or the latest version of some specific major version). Also note the peer dependency on the webidl2.js parser.
@tidoust I wonder if this is something we should provide via strudy - i.e. add to the strudy the ability to report errors based on the immediate reffy-ing of a particular spec
(Creating the issue to document the idea somewhere following discussions with @dontcallmedom. Not sure whether we'll work on this any time soon :))
The IDL validation in spec-prod only validates the spec IDL in isolation. This prevents detection of errors such as referencing interfaces that do not exist in other specs, creating IDL that duplicates IDL defined in another spec, or even simple typos such as using
bool
instead ofboolean
.The action could leverage the
@webref/idl
package to merge the spec IDL with the rest of the Web platform's IDL and validate the whole thing to report such issues.Some notes and open questions:
@webref/idl
package (based on the spec's shortname)@webref/idl
package is released once per week, so checks may validate the spec IDL with IDL extracts that are one week old. Our assumption is that this won't cause any real issue as specs often reference "stable" IDL from other specs.@webref/idl
package. This may make the validation report on errors that do not really exist. There should be a way to disable that validation.@webref/idl
package. The code should rather install the latest version of the package (or the latest version of some specific major version). Also note the peer dependency on the webidl2.js parser.