From 350185de8c72ae0c8cea0f4031d1580a88a57a2d Mon Sep 17 00:00:00 2001
From: Samuel Maddock <smaddock@slack-corp.com>
Date: Mon, 30 Sep 2024 13:16:01 -0400
Subject: [PATCH] docs: type definition changes are not breaking

---
 wg-api/README.md         | 1 +
 wg-api/best-practices.md | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/wg-api/README.md b/wg-api/README.md
index 46187177d..c73c396bc 100644
--- a/wg-api/README.md
+++ b/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.
diff --git a/wg-api/best-practices.md b/wg-api/best-practices.md
index db17382e7..97cd945fa 100644
--- a/wg-api/best-practices.md
+++ b/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]  
+> Changes that only affect TypeScript type definitions are not considered breaking changes.
+
 ### 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?