Consider splitting CommonMark and GFM specs out of GLFM `spec.txt`
The following discussion from !98493 (merged) should be addressed:
-
@digitalmoksha started a discussion: (+2 comments)
After thinking about this more, I don't think we should include the CommonMark and GFM specs inside our own, for the official
spec.txt
. I think it overly complicates and obfuscates the specification.I understand that GFM has their extensions embedded inside a copy of the CommonMark spec. But I just don't think we need it. The intro to the spec can clearly layout our assumption that any implementation of GLFM should also pass the GH conformance tests.
However the GFM spec should, of course, be included as input in ouroverall conformance test.
That's a really good point, and might be a good idea. I had just assumed we'd be consistent with what GFM did with respect to spec.txt
/spec.html
, but as you say we can do whatever we want.
Programatically, it's easy to split files up however we want, and change the code accordingly to read them all at runtime.
However, I think workflow-wise, especially for the snapshot testing, it's less cognitive overload to have the complete superset of all supported listed in the same spec.txt
rather than having to deal with them split across multiple files.
But that's just my opinion, and I there's other pros and cons to consider as well.
Let's discuss the tradeoffs, and get input from @ealcantara and @himkp, who have been the main ones actually using this so far.