feat: Allow UUIDv6/7/8 in UUIDField validation #221
Conversation
Why --- Currently the UUIDField type supports only UUIDv1-5 and to use a newer UUID version we need to use StringField. How --- Manually implemented UUID validation, adding support for versions 6, 7, and 8. Also added support for the "max" UUID, which is now part of the spec. Test Plan --- Added a UUIDv7 value (from https://uuid7.com/).
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #221 +/- ##
=======================================
Coverage 95.46% 95.46%
=======================================
Files 79 79
Lines 2074 2074
Branches 258 282 +24
=======================================
Hits 1980 1980
+ Misses 93 88 -5
- Partials 1 6 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| @@ -1,7 +1,9 @@ | |||
| import { validate as validateUUID } from 'uuid'; | |||
There was a problem hiding this comment.
Should we make this a dev dependency?
There was a problem hiding this comment.
It turns out uuid is used by StubDatabaseAdapter, which ends up getting exported as part of the package's production interface. So for now the right thing to do AFAIK is to keep it as as dependency. If we introduced @expo/entity-testing as a separate package, we could make uuid a devDep of @expo/entity but I don't think that'd get us much.
Why
Currently the UUIDField type supports only UUIDv1-5 and to use a newer UUID version we need to use StringField.
How
Manually implemented UUID validation, adding support for versions 6, 7, and 8. Also added support for the "max" UUID, which is now part of the spec.
Test Plan
Added a UUIDv7 value (from https://uuid7.com/) to the test cases.