Conversation
Liqe only recognizes uppercase AND, OR, NOT as boolean operators. Lowercase variants (and, or, not) were treated as bare search terms, producing ImplicitField AST nodes that lack an operator property, causing 'Cannot read properties of undefined' crashes during QueryKit's AST conversion. The fix adds a normalizeBooleanOperators step to preprocessQuery that uppercases and/or/not outside of quoted strings before passing to Liqe. Fixes #19
Add parserOptions to IQueryKitOptions, passed through to the QueryParser constructor. This enables field mappings and case-insensitive field names at the createQueryKit level without requiring consumers to build fragile string-level preprocessing. Add tolerant mode (tolerant: boolean) that uses parseWithContext with autofix recovery instead of parse, allowing the execution pipeline to gracefully handle incomplete queries (trailing operators, unclosed quotes, unbalanced parentheses) — useful for search UIs where queries may be submitted in transiently incomplete states. Fixes #19
…erators Update README to cover: - parserOptions (fieldMappings, caseInsensitiveFields) configuration - Tolerant parse mode for search UIs with autofix recovery - Case-insensitive boolean operators (and/or/not) in query syntax Ref #19
|
Cursor Agent can help with this pull request. Just |
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
The regex \b(and|or|not)\b matched at colon boundaries, causing unquoted field values like name:and to become name:AND — which Liqe rejects because uppercase AND/OR/NOT are reserved boolean keywords. Replace word-boundary anchors with context-aware lookarounds that only match when the keyword is in boolean operator position: surrounded by whitespace, parentheses, or string boundaries. This correctly preserves and/or/not as field values, comparison operands, and field names while still normalizing them as operators. Fixes #19
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.
Implement case-insensitive boolean operators, expose parser options, and add a tolerant parsing mode to address issue #19.
The primary bug fixed involved lowercase boolean operators (
and,or,not) causing crashes because Liqe only recognizes uppercase versions, treating lowercase as bare search terms. This PR normalizes these operators before parsing. Additionally, a newtolerantmode leverages Liqe'sparseWithContextto automatically fix common query syntax errors like unclosed quotes or trailing operators, significantly improving user experience.