Repository navigation
Conversation
🦋 Changeset detectedLatest commit: 25fbf42 The changes in this PR will be included in the next version bump. This PR includes changesets to release 31 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
|
Closing in favor of #8482 |
This branch is waiting to be deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Exporting
Schema.String.check(Schema.isMaxLength(1))currently produces{ type: "string", maxLength: 1 }. Effect rejects"😀"because it has two UTF-16 code units, while that JSON Schema accepts it as one Unicode code point.isMinLength(2)has the reverse problem: the exported schema rejects a value that Effect accepts.This addresses the string-length export part of #8358 and the mismatch reported in #6336. It builds on #8459, which fixes JSON Schema imports. Importing JSON Schema and exporting existing UTF-16 checks are separate paths.
The chosen approach preserves the runtime meaning of
isMinLength,isMaxLength, andisBetweenLength. Their JSON Schema callbacks now reject unsupported string bounds with an error directing callers to the corresponding code-point check or an explicittoJsonSchemacheck annotation. Array mappings, code-point checks, and the supported empty/non-empty string cases continue to export.This is an intentional compatibility change for JSON Schema generation and a proposal for maintainer review. Existing callers that export nontrivial UTF-16 string bounds, including
Schema.Char, will now receive an error. Switching to code-point checks also changes runtime validation; applications that need UTF-16 semantics must retain those checks and provide a deliberate export mapping. The PR implements the explicit-refusal direction described in #8358 without adding a general strict-export mode.The regression cases cover both export entry points, nested definitions, unchanged emoji validation, and a custom mapping checked against BMP characters, astral characters, combining sequences, lone surrogates, and line breaks. Existing annotation/reference examples now use code-point checks where their expected output is a JSON Schema length bound.
Other check mappings in #8358 remain outside this PR.