docs: type definition changes are not breaking (#585)

* docs: type definition changes are not breaking

* lint

* docs: clarify runtime vs static compilation

wg-api/README.md

@@ -26,6 +26,7 @@ Oversees public API design based on project principles.
   | <img src="https://github.com/zcbenz.png" width=100 alt="@zcbenz">  | Cheng Zhao [@zcbenz](https://github.com/zcbenz) | Member | JST (Nagoya) |
 
 </details>
+
 ## Areas of Responsibility
 
 * Define the process for which API changes are reviewed and approved.

wg-api/best-practices.md

@@ -12,6 +12,9 @@ API changes which alter existing behavior can cause apps to break unexpectedly w
 
 If the behavior must change to support the feature, the change should be listed in [the breaking changes document](https://github.com/electron/electron/blob/main/docs/breaking-changes.md). Additionally, consider whether the change can be introduced in a way which permits a deprecation cycle, for instance introducing the new API under a new name and deprecating the old name while keeping the behavior unchanged for apps using the API under the old name.
 
+> [!NOTE]
+> Breaking changes should be that which affects JavaScript runtime usage. If a change affects type definitions which breaks static compilation of a TypeScript app, that is not enough to be considered a breaking change.
+
 ### How will this API be extended in the future?
 
 What additional changes can you imagine being made to this API in the future? Are there any features that are not in the first version of a change you’re making that you would like to include in the future?