Closed dontcallmedom closed 2 years ago
I agree with the goal.
I think it is a mistake to split the specification names from the rest of the specification data, and is just a side effect of how the KumaScript macro was used. We can fix that with this transition.
Here's how I would do it:
spec2.ejs
and SpecName.ejs
into SpecData.json
, inside the KumaScript repo. This would be similar to how ListGroups loads GroupData.json. A utility function should be written to abstract how the data is loaded.SpecData.json
to this repo, merge PR, deploydata
package instead of SpecData.json
The benefit to this method is that you don't have to coordinate KumaScript and data releases, but instead deal with a little data duplication between repos while things are shaking out.
given the update to https://github.com/mdn/kumascript/pull/557 maybe we're better off closing this pull request for now?
Spring cleaning this repo & am closing due to age and archiving of kumascript.
The W3C community has built over time a series of tools and APIs that enable to determine a number of MDN-relevant information about specs (including title, editors and TR URLs, statuses, github repos, test suites).
To make it easier to use these tools to verify and update the data currently used in MDN (and currently hosted in kumascript macros https://github.com/mdn/kumascript/blob/master/macros/spec2.ejs & https://github.com/mdn/kumascript/blob/master/macros/SpecName.ejs, it would be much easier if the data was kept separated from the template themselves.
I have provided pull requests to that effect: https://github.com/mdn/data/pull/157 and https://github.com/mdn/kumascript/pull/557
This issue is raised to discuss the goals and approaches as requested.