Is your feature request related to a problem? Please describe.
The doc.go already acknowledges that Go's regexp package differs from ECMA 262 (no back-references, no lookahead/lookbehind). This is documented under "Deviations from the specification" with a link to the regexp2 comparison table.
Currently, there is no way to plug in an alternative regexp engine. Users working with schemas that use PCRE-specific features (e.g., (?=...) lookahead in pattern or patternProperties) cannot validate them correctly.
Describe the solution you'd like
Add a RegexpCompiler option to ResolveOptions that allows users to provide a custom regexp compiler. The default behavior remains unchanged (Go's regexp.Compile).
The proposed API:
// A Regexp is a compiled regular expression.
type Regexp interface {
MatchString(s string) bool
}
// A RegexpCompiler compiles a regular expression pattern string into a Regexp.
type RegexpCompiler func(pattern string) (Regexp, error)
type ResolveOptions struct {
// ... existing fields ...
// RegexpCompiler compiles regular expression patterns used in "pattern" and
// "patternProperties" keywords. If nil, Go's regexp.Compile is used.
RegexpCompiler RegexpCompiler
}
Usage with regexp2 (note: regexp2.MatchString returns (bool, error), so an adapter is needed):
import "github.com/dlclark/regexp2"
type regexp2Adapter struct {
re *regexp2.Regexp
}
func (r regexp2Adapter) MatchString(s string) bool {
ok, err := r.re.MatchString(s)
return err == nil && ok
}
compiler := func(pattern string) (jsonschema.Regexp, error) {
re, err := regexp2.Compile(pattern, regexp2.ECMAScript)
if err != nil {
return nil, err
}
return regexp2Adapter{re: re}, nil
}
resolved, err := schema.Resolve(&jsonschema.ResolveOptions{
RegexpCompiler: compiler,
})
Implementation details
- Minimal interface:
Regexp requires only MatchString(string) bool, matching the existing validation path and avoiding changes to runtime validation semantics
- Internal
resolvedInfo stores Regexp interface instead of *regexp.Regexp
validate.go should require little or no change, since validation already only needs MatchString semantics
doc.go "Deviations" section updated to mention the escape hatch
- Full test coverage: custom compiler for
pattern, patternProperties, and error propagation
- Fully backwards-compatible —
nil RegexpCompiler defaults to regexp.Compile
PR: #73
Is your feature request related to a problem? Please describe.
The
doc.goalready acknowledges that Go'sregexppackage differs from ECMA 262 (no back-references, no lookahead/lookbehind). This is documented under "Deviations from the specification" with a link to the regexp2 comparison table.Currently, there is no way to plug in an alternative regexp engine. Users working with schemas that use PCRE-specific features (e.g.,
(?=...)lookahead inpatternorpatternProperties) cannot validate them correctly.Describe the solution you'd like
Add a
RegexpCompileroption toResolveOptionsthat allows users to provide a custom regexp compiler. The default behavior remains unchanged (Go'sregexp.Compile).The proposed API:
Usage with
regexp2(note:regexp2.MatchStringreturns(bool, error), so an adapter is needed):Implementation details
Regexprequires onlyMatchString(string) bool, matching the existing validation path and avoiding changes to runtime validation semanticsresolvedInfostoresRegexpinterface instead of*regexp.Regexpvalidate.goshould require little or no change, since validation already only needsMatchStringsemanticsdoc.go"Deviations" section updated to mention the escape hatchpattern,patternProperties, and error propagationnilRegexpCompilerdefaults toregexp.CompilePR: #73