You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue occurs immediately after upgrading from 21.4.4 to 21.4.5 with no other dependency changes.
No runtime errors occur — this is strictly a compile-time TypeScript issue.
How can we help?
After upgrading from 21.4.4 to 21.4.5, our TypeScript build started failing due to changes in type definitions (for example, any was changed to string | string[]).
Type 'string | string[]' is not assignable to type 'string'.
This required us to update multiple parts of the codebase to add type narrowing or assertions, even though runtime behavior has not changed.
We understand that the new typing is more accurate and improves type safety. However, since this change introduces compile-time breaking changes for consumers, we would like clarification:
Are TypeScript type definition changes considered part of the SemVer guarantees?
Should compile-time breaking changes be treated as breaking (major) version bumps?
We’re mainly looking for guidance on versioning expectations so we can plan upgrades accordingly.
While we try to limit major type changes to breaking releases, hapi doesn't provide any guarantee that your code will compile without changes after a new release. This matches the TypeScript language itself, which doesn't adhere to semver.
Agreed, and in this specific case, types were wrong or too permissive, so it would still be considered a bug. In general, type breakage is so easy to trigger that it's guaranteed to happen, hapi or not.
Activity
kanongil commentedon Feb 18, 2026
This is largely as expected.
While we try to limit major type changes to breaking releases, hapi doesn't provide any guarantee that your code will compile without changes after a new release. This matches the TypeScript language itself, which doesn't adhere to semver.
Marsup commentedon Feb 18, 2026
Agreed, and in this specific case, types were wrong or too permissive, so it would still be considered a bug. In general, type breakage is so easy to trigger that it's guaranteed to happen, hapi or not.