feat: Allow tokenizers to accept arbitrary options - #49
Merged
Conversation
isaacvando
requested review from
mdashti,
philippemnoel,
rebasedming and
stuhood
as code owners
May 22, 2026 18:20
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #49 +/- ##
==========================================
- Coverage 91.72% 87.25% -4.47%
==========================================
Files 30 29 -1
Lines 423 361 -62
Branches 37 37
==========================================
- Hits 388 315 -73
- Misses 27 34 +7
- Partials 8 12 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
philippemnoel
approved these changes
May 22, 2026
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
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.
Ticket(s) Closed
Updates the tokenizers to accept explicit positional arguments (like int minGram, etc) and a dictionary of arbitrary options. This matches what we have in other ORMs and prevents us from having to wrap all of the many options each tokenizer can accept. Provides less type-safety than an explicit wrapping, but it makes the maintenance burden much lighter and it removes the possibility of a user ever needing an option that we hadn't exposed yet. The old API would have needed to get much larger to support all of the options (like alias) too.
What
Why
How
Tests