SwiftDocC: use "portable" paths for file names #668
Conversation
Some file systems have restrictions on character sets which are valid file name characters. Add a filter for the Windows file system character set restrictions. We replace them with `_` to match the behaviour in the DocC bundle generation after apple/swift-docc#668.
Some file systems have restrictions on character sets which are valid file name characters. Add a filter for the Windows file system character set restrictions. We replace them with `_` to match the behaviour in the DocC bundle generation after apple/swift-docc#668.
|
This has the associated change in the docc-render application to permit the continued use of the characters in the URL. |
|
@swift-ci please test |
| let components = name.components(separatedBy: ["<", ">", ":", "\"", "/", "\\", "|", "?", "*"]) | ||
| if components.count > 1 { | ||
| isURLModified = true | ||
| name = components.joined(separator: "_") |
There was a problem hiding this comment.
I wonder if we should always append a hashed identifier to the name here to ensure that the file names don't collide.
There was a problem hiding this comment.
I think that appending the hashed identifier seems reasonable. Definitely would avoid any possible conflicts. Would we do that for any case where isURLModified is true?
There was a problem hiding this comment.
The code already mostly does that when modifying the URL, although if it's a specific path component that's longer than what a file name is allowed to be, then it shortens that path component and appends the hash to that component instead of later in the URL.
| "/tutorials/Technology-file:-with---whitespace,-and_punctuation/Volume_Section-Title:-with---various!-whitespace,-and/punctuation", | ||
| "/tutorials/Technology-file:-with---whitespace,-and_punctuation/Volume_Section-Title:-with---various!-whitespace,-and/punctuation/Chapter_Title:-with---various!-whitespace,-and/punctuation" | ||
| "/tutorials/Technology-file_-with---whitespace,-and_punctuation/Volume_Section-Title:-with---various!-whitespace,-and/punctuation", | ||
| "/tutorials/Technology-file_-with---whitespace,-and_punctuation/Volume_Section-Title:-with---various!-whitespace,-and/punctuation/Chapter_Title:-with---various!-whitespace,-and/punctuation" |
There was a problem hiding this comment.
Is it expected that the : towards the end of this string ("Chapter_Title:") isn't replaced with _?
There was a problem hiding this comment.
No, that isn't expected, but how did the test pass 🤯. : is a ADS (alternate data stream, think of it as macOS file forks) separator, the file would just be truncated to the : and the rest would be the name of the stream.
| @@ -276,7 +276,7 @@ class ExternalLinkableTests: XCTestCase { | |||
| let summary = node.externallyLinkableElementSummaries(context: context, renderNode: renderNode)[0] | |||
|
|
|||
| XCTAssertEqual(summary.title, "globalFunction(_:considering:)") | |||
| XCTAssertEqual(summary.relativePresentationURL.absoluteString, "/documentation/mykit/globalfunction(_:considering:)") | |||
| XCTAssertEqual(summary.relativePresentationURL.absoluteString, "/documentation/mykit/globalfunction(__considering_)") | |||
There was a problem hiding this comment.
I don't think this value should change. It represents the relative URL for this page. As far as I understood the URL would still contain the characters that aren't allowed in the file names.
There was a problem hiding this comment.
Right, the URLs can contain the view, but the file paths would be replaced. I believe that the replativePresentationURL is still referencing the file path?
There was a problem hiding this comment.
No, this is meant to refer to the web URL relative to where this documentation is hosted.
This API is used to bridge with other documentation systems which aren't expected to have access to the doccarchive directly. Those systems are expected to use the summary information to create links that navigate the reader to the hosted documentation.
There was a problem hiding this comment.
It can also refer to a landmark on a page which wouldn't have its own file in the documentation archive.
| @@ -96,7 +96,7 @@ final class RenderIndexTests: XCTestCase { | |||
| "type": "groupMarker" | |||
| }, | |||
| { | |||
| "path": "/documentation/mixedlanguageframework/bar/mystringfunction(_:)", | |||
| "path": "/documentation/mixedlanguageframework/bar/mystringfunction(__)", | |||
There was a problem hiding this comment.
@ethan-kusters do you remember if this value represents the path of the web URL or the file path within the documentation archive? I thought that this is the path that the browser would load to access this page.
Some file systems have restrictions on character sets which are valid file name characters. Add a filter for the Windows file system character set restrictions. We replace them with `_` to match the behaviour in the DocC bundle generation after apple/swift-docc#668.
Some file systems have restrictions on character sets which are valid file name characters. Add a filter for the Windows file system character set restrictions. We replace them with `_` to match the behaviour in the DocC bundle generation after apple/swift-docc#668. Conditionally enable the new portable paths based upon a setting in `theme-settings.json` to provide a means for compatibility.
d-ronnqvist
added
the
needs forum discussion
Windows restricts a CharacterSet from use in the file name. Replace that set with `_`. This requires an associated change in the DocC renderer to perform the substitution when converting the URL to a file path.
|
@d-ronnqvist this would be nice to get in for 6.0 |
|
This is not ready to be merged. I added the "needs forum discussion" tag because this previous Swift Forums thread or the Workgroup meeting where this topic was discussed didn't reach a specific conclusion for how to best solve this problem. It seems like the solution would be to add an opt-in feature flag, communicate about the change and the possible disruption in the Swift Forums, and then reevaluate after one minor release if we should change the default behavior top opt-out instead of opt-in. However, it might be good to revive that thread just to confirm that everyone is happy with that solution. If so, what's missing from this PR is adding that flag and making the behavior conditional. |
Windows restricts a CharacterSet from use in the file name. Replace that set with
_. This requires an associated change in the DocC renderer to perform the substitution when converting the URL to a file path.