Skip to content

Add support for custom scripts #1056

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

Lucca-mito
Copy link

@Lucca-mito Lucca-mito commented Oct 13, 2024

Summary

First-class support for adding custom scripts to a DocC-generated website. These may be local scripts, in which case the website will continue to work offline, or they may be external scripts at a user-specified URL. This support is in the form of a custom-scripts.json file, the scripting analog of theme-settings.json.

Full pitch: https://forums.swift.org/t/pitch-support-for-custom-scripts-in-docc/75357.

Dependencies

Corresponding change in swift-docc-render.

Testing

  • Unit tests added.
  • To test the feature end-to-end, you'll need to use the version of swift-docc-render with the corresponding changes. Follow the steps in the pitch for adding any custom scripts you want to your documentation website (your own scripts, or a library such as MathJax or D2). If you want a specific example to test the implementation:
    • Copy the custom-scripts.json and the custom mathjax-config.js script (shown in the pitch) to your documentation catalog.
    • Add LaTeX expressions to your in-source documentation.
    • docc convert the documentation catalog with your custom scripts. Observe that the modified swift-docc copied custom-scripts.json and the custom scripts into the documentation archive.
    • Preview the documentation archive. Observe that the LaTeX expressions are rendered on the page.
  • Live demo: see here and here. The LaTeX expressions in the documentation text are dynamically rendered into equations via custom scripts.

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

  • Added tests
  • Ran the ./bin/test script and it succeeded
  • Updated documentation if necessary
    • Existing documentation does not need to change. New documentation for this feature will be added after the design and implementation are finalized.

Copy link
Contributor

@d-ronnqvist d-ronnqvist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is making an unintentional source breaking change that should be undone.

Additionally, we're in the process of migrating away from LocalFileSystemDataProvider so the new code to find the custom-scripts.json file also need to be added to DocumentationContext.InputProvider. There's already a test that verifies that both implementation discover the same files which would also be good to update so that it verifies the behavior for this new type of file.

@d-ronnqvist d-ronnqvist added the source breaking DocC's public API isn't source compatible with earlier versions label Oct 16, 2024
@@ -120,6 +120,18 @@ struct ConvertFileWritingConsumer: ConvertOutputConsumer {
for downloadAsset in context.registeredDownloadsAssets(forBundleID: bundleIdentifier) {
try copyAsset(downloadAsset, to: downloadsDirectory)
}

// Create custom scripts directory if needed. Do not append the bundle identifier.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not append the bundle ID here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • So that projects with combined documentation of multiple targets (when that lands) can share scripts between the documentation bundles of each target. I suspect that authors of packages with multiple targets will want scripts to be shared: nobody wants to set up their MathJax scripts once per target.
  • In practice, even in documentation webpages for multiple targets, custom scripts loaded into the browser are global. For example, scripts that define the same global function can conflict with each other irrespective of the bundle they were loaded from. So namespacing the script files by bundle ID is moot.

(Also, if the relative path to the custom-scripts folder is always "/custom-scripts" then it’s easier to find it in the renderer code.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. That's not how combined documentation works (which is already available as an experimental feature). Non-content files aren't automatically included in the combined archive. If this was treated as an asset, a collision between archives would be treated as an error. If this file is intended to be copied over into the combined archive, it should have an archive-unique prefix and this PR should update the merge command to copy over the expected files.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey David,

Sorry for the confusion; I hadn’t read your combined-documentation proposals yet and was operating under some admittedly hasty guesswork. Having read them now — the second, lower-level pitch in particular — I wasn't able to find more information on how combined documentation handles assets.

So I looked through the swift-docc code. But I haven't yet been able to find code for merging documentation archives, or for handling assets during that merge (the closest I could find was this, which seems related to merging assets of documentation archives given the phrasing here), or for including additional "non-symbol content for the landing page of the combined documentation" (a feature of docc merge you described in the technical pitch that could be relevant here). I'm definitely missing something obvious so apologies for the question, but where in the swift-docc codebase does documentation-archive merging happen? Essentially, I'm trying to figure out:

  • How documentation-archive merging handles the theme-settings.json files of the archives being combined, so I can do the same to custom-scripts.json.
  • How documentation-archive merging handles images, so I can do the same to the individual JS scripts in the archive's custom-scripts directory. (Assuming that doing so wouldn't break custom scripts, which I'll also look into.)

Thanks!!

@Lucca-mito Lucca-mito force-pushed the main branch 2 times, most recently from cb3a07b to b8512d2 Compare March 5, 2025 02:54
@d-ronnqvist d-ronnqvist removed the source breaking DocC's public API isn't source compatible with earlier versions label Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants