Introducing API History (GSoC 2024)
Historical changes to Electron APIs will now be detailed in the docs.
Hi 👋, I'm Peter, the 2024 Google Summer of Code (GSoC) contributor to Electron.
Over the course of the GSoC program, I implemented an API history feature for the Electron documentation and its functions, classes, etc. in a similar fashion to the Node.js documentation: by allowing the use of a simple but powerful YAML schema in the API documentation Markdown files and displaying it nicely on the Electron documentation website.
Details
API history documentation system / YAML schema
In the Markdown API documentation, the history for a function/class/etc. is now placed directly after the header for that item in the form of a YAML code block encapsulated by an HTML comment.
#### `win.setTrafficLightPosition(position)` _macOS_
<!--
```YAML history
added:
- pr-url: https://github.com/electron/electron/pull/22533
changes:
- pr-url: https://github.com/electron/electron/pull/26789
description: "Made `trafficLightPosition` option work for `customButtonOnHover` window."
deprecated:
- pr-url: https://github.com/electron/electron/pull/37094
breaking-changes-header: deprecated-browserwindowsettrafficlightpositionposition
```
-->
* `position` [Point](structures/point.md)
Set a custom position for the traffic light buttons. Can only be used with `titleBarStyle` set to `hidden`.
I believe using YAML like the Node.js docs do was the best approach because it is easy to read. The API history isn't extremely complicated and should ideally be as easy to write and read as possible.
The final design shown above is actually significantly different to the one I proposed:
<!--
```YAML history
added: v10.0.0
deprecated: v25.0.0
removed: v28.0.0
changes:
- version: v13.0.0
pr-url: https://github.com/electron/electron/pull/26789
description: Made `trafficLightPosition` option work for `customButtonOnHover` window.
```
-->
One large change is the removal of version numbers:
"[...] There’s one somewhat significant change we’d like to call out about the proposal, which came up during discussion when we were reviewing proposals. [...]
[we] decided that the approach with the [fewest] drawbacks would be to only use PR URLs (the root PRs to main) instead of hardcoded version strings as in the proposal.
This can serve as a single source of truth which can then be used to derive exact version numbers, and no further documentation changes on main are necessary if the change is backported to other branches."
— David Sanders (@dsanders11) via Slack
We also didn't include removals in the API History, since when an API is removed from Electron, it is also removed from the documentation.
JavaScript implementation
I originally planned to create a new @electron/docs-api-history-tools
npm package that would contain scripts for extracting, validating/linting and converting
the API history in the documentation files.
About a week before the coding period began, and after some discussion with my mentors, I realized that was probably unnecessary:
"Hi everyone, I was thinking about the project after our huddle: Considering that extraction logic will have to be handled differently in
e/website
ande/lint-roller
because of their dependencies, maybe there is no need for a separate package for API history stuff?"
Proposed Revised — Piotr Płaczek (me) via Slack
We ultimately decided to not go ahead with my original idea:
"@Piotr Płaczek that seems fine to me! I think we can always refactor out to a separate module in a later iteration if we find that we need to share a lot of code between the two implementations anyways 🙂"
— Erick Zhao (@erickzhao) via Slack
Instead, we divided those various tools across the Electron repos that were most relevant to them:
yaml-api-history-schema.json
- ->
electron/electron
(api-history.schema.json
)
- ->
lint-yaml-api-history.ts
- ->
electron/lint-roller
(lint-markdown-api-history.ts
)
- ->
extract-yaml-api-history.ts
- ->
electron/website
(preprocess-api-history.ts
)
- ->
yaml-api-history-to-markdown.ts
- ->
electron/website
(transformers/api-history.ts
) - ->
electron/website
(ApiHistoryTable.tsx
)
- ->
UI and styling for Electron documentation website
I originally proposed a simple table to display the API History data:
Design Prototype (Closed) | Design Prototype (Open) |
---|---|
This is what the final implemented design looks like:
Pretty much the same as the prototype. The most significant addition is the use of SemVer ranges, which were chosen to better communicate which versions a feature is present in (thanks Samuel Attard (@MarshallOfSound) for the suggestion!).
This is important because changes are frequently backported across supported Electron release lines e.g. a fix may make it into Electron v32.0.0, v31.1.0 and v30.2.0. This means it is not present in v31.0.0 which a user might mistakenly deduce based on the fact it is present in a v30.x.x release.
Usage/style guide
I added a usage/style guide dedicated to writing API history documentation for new features. I described proper usages of the YAML schema in detail, provided typical/useful examples, etc. You can find it here.
Migration guide
Since existing APIs have to be migrated to the new documentation system, I created a migration guide. It features the typical steps of what a developer has to do when migrating old APIs: looking through breaking changes, browsing through the past releases, maybe looking through old commits, etc. Then instructing the developer to follow the usage/style guide to add API history documentation for each previously existing class/function/etc.
Sadly, I couldn't think of a way to automate this effectively. This would probably be a great task for an AI/ML engineer; however, I don't possess those skills and was too afraid of accidentally introducing hallucinations into the API history. Even if automated, the information would still probably have to be verified by a human in the end 😕. This task will probably have to be done manually, on a file-by-file basis, just like it was done for the Node.js documentation.
Deliverables
-
api-history.schema.json
- A comprehensive YAML schema for documenting API history which includes support
for:
- Additions
- Deprecations
- Changes
- Links to relevant pull requests
- Backports
- Proposed in: electron/rfc#6
- Implemented/Used in: electron/electron#42982
- Used in: electron/website#594
- A comprehensive YAML schema for documenting API history which includes support
for:
-
lint-markdown-api-history.ts
- Script for linting YAML API history written according to a custom YAML
(technically JSON) schema.
- Useful error messages
- Comprehensive documentation / code comments
- Extensive
JestVitest tests - Good performance
- Implemented in: electron/lint-roller#73
- Used in: electron/electron#42982
- Script for linting YAML API history written according to a custom YAML
(technically JSON) schema.
-
preprocess-api-history.ts
- Performs simple validation just in case incorrect API History manages to make it into the repo. Also strips the HTML comment tags that wrap API History blocks since Docusaurus cannot parse them.
- Implemented/Used in: electron/website#594
-
transformers/api-history.ts
- Script for converting YAML API history blocks in the Markdown documentation files
to
Markdown/HTMLReact tables (ApiHistoryTable.tsx
). - Implemented/Used in: electron/website#594
- Script for converting YAML API history blocks in the Markdown documentation files
to
-
ApiHistoryTable.tsx
- React table component used to display parsed API History data on the
documentation website.
- Uses styling that follows the rest of the website's design.
- Responsive, accessible, and generally well written HTML, CSS, and JS.
- Implemented/Used in: electron/website#594
- React table component used to display parsed API History data on the
documentation website.
-
styleguide.md
- Usage/style guide section for new API history documentation system.
- Easy to understand
- Well written
- Includes examples
- Implemented/Used in: electron/electron#42982
- Usage/style guide section for new API history documentation system.
-
api-history-migration-guide.md
- Migration guide for new API history documentation system.
- Easy to understand
- Well written
- Includes examples
- Implemented/Used in: electron/electron#42982
- Migration guide for new API history documentation system.