Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ingesting DocC archives or JSON as input #1256

Open
jpsim opened this issue Jun 9, 2021 · 3 comments
Open

Add support for ingesting DocC archives or JSON as input #1256

jpsim opened this issue Jun 9, 2021 · 3 comments

Comments

@jpsim
Copy link
Collaborator

jpsim commented Jun 9, 2021

Instead of passing in a SourceKitten JSON file, jazzy could ingest a DocC archive or the JSON file(s) embedded within as input.

This could help users who've invested in custom themes or other jazzy features over the years get the benefits of using DocC as the documentation collection part of the pipeline.

I'm attaching the Yams DocC documentation archive as generated by Xcode 13 beta 1 which we can use as a reference. Yams.doccarchive.zip

The JSON files under data/documentation seem to have everything we currently get from SourceKitten. There seems to be a JSON file for every declaration included in the documentation, but it might be sufficient to just read the JSON file at the root (e.g. Yams.doccarchive/data/documentation/yams.json) I'm not sure yet.

Obviously with DocC being (currently) closed source and this JSON format likely being in flux and subject to change at any time, we probably can't rely on the exact format staying stable, but this can still be worthwhile even with that risk.

@jpsim
Copy link
Collaborator Author

jpsim commented Jun 9, 2021

cc @johnfairh

@johnfairh
Copy link
Collaborator

The top-level yams.json looks to have just the top-level contents, the directory structure below has the individual symbol data and hierarchy.

Although this is derived from symbolgraph json (that jazzy understands) it is heavily munged to exactly match the apple docs design (eg. markdown has been parsed and reserialized, extensions have been merged).

Probably the least painful approach for a jazzy importer is to go straight to the SourceDeclaration level without trying to make up the SourceKit structures, mainly because the extensions have already been sorted out and marked up.

It looks like they haven't yet decided what to do with extensions of types from other modules.

@eneko
Copy link

eneko commented Jun 30, 2021

Maybe this is something that SourceKitten could handle, taking an input instead of parsing the code?

This would allow for any tools using SourceKitten, not just Jazzy, to take advantage of this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants