From 3ed9e923095808d2cdf8944bec41a96e078a4e04 Mon Sep 17 00:00:00 2001 From: Sam Maddock Date: Fri, 4 Oct 2024 10:53:05 -0400 Subject: [PATCH] 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 | 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. | @zcbenz | Cheng Zhao [@zcbenz](https://github.com/zcbenz) | Member | JST (Nagoya) | + ## 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..b962265f3 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] +> 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?