Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infer the literals used in the type of the groups #235

Open
michaelschufi opened this issue Mar 2, 2023 · 10 comments
Open

Infer the literals used in the type of the groups #235

michaelschufi opened this issue Mar 2, 2023 · 10 comments
Assignees
Labels
enhancement New feature or request

Comments

@michaelschufi
Copy link

michaelschufi commented Mar 2, 2023

🆒 Your use case

When I create a regexp group using anyOf and groupedAs, the type of the matched group should be inferred based on the inputs to anyOf.

Similar to the type of the main regexp that gets inferred.

E.g.

const regex = createRegExp(
  anyOf("A", "B", "C")
    .groupedAs("opponent")
    .and(" ")
    .and(anyOf("X", "Y", "Z").groupedAs("self")),
);

Here, the type of regex is

MagicRegExp<"/(?<opponent>A|B|C) (?<self>X|Y|Z)/", "opponent" | "self", ["(?<opponent>A|B|C)", ...any[]], never>

so the information that the groups have literals of ABC and XYZ respectively is included in the type. However, the type of

"A Y".match(regex)?.groups.opponent

is string | undefined instead of "A" | "B" | "C".

🔍 Alternatives you've considered

No response

ℹ️ Additional info

My goal is to use this library in conjunction with colinhacks/zod. magic-regexp complements zod well when it comes to string validation and parsing while still being typesafe.

I'm open to work on this myself. Please let me know where I should have a look to get started with such a feature.

@michaelschufi michaelschufi added the enhancement New feature or request label Mar 2, 2023
Copy link
Member

This is definitely a worthy enhancement. I think @didavid61202 might be working on this very thing (so let's wait to hear from him), but if not then contribution would be very welcome ❤️

@didavid61202 didavid61202 self-assigned this Mar 2, 2023
@didavid61202
Copy link
Collaborator

didavid61202 commented Mar 2, 2023

Hi @michaelschufi,

Yes, I've been working on features similar to this, although might be in very different approach, it's a new type inferencing (fully parse, interpret, exact match, permutation all possible values) for string.match, string.replace, string.matchAll and string.replaceAll,

a little peek at what's possible (blue text are type hints from vscode-twoslash-queries), still testing out with pure string literal:
type_level_regexp

Still have to finish writing more robust test cases and testing for some edge cases.

@michaelschufi
Copy link
Author

Yes, I've been working on a new type inferencing (fully parse, interpret, exact match, permutation all possible values) for string.match, string.replace, string.matchAll and string.replaceAll

Sounds awesome! 😀
Of course, if the other functions can also benefit of the inference, it's even better. I haven't worked yet with .replace with this library, but this sounds really game changing. It makes it so much easier to work with string manipulation of all kind.

The inference looks great so far. Tell me if I can help with some testing or similar.

@didavid61202
Copy link
Collaborator

Sounds awesome! 😀

Of course, if the other functions can also benefit of the inference, it's even better. I haven't worked yet with .replace with this library, but this sounds really game changing. It makes it so much easier to work with string manipulation of all kind.

The inference looks great so far. Tell me if I can help with some testing or similar.

Definitely would love to have some helps on testing and improving it! ❤️

Will let you know as soon as I finish wrapping it up. 👍

@didavid61202
Copy link
Collaborator

didavid61202 commented Mar 9, 2023

Hi @michaelschufi, Here's the repository for the type-level RegExp parser and matcher. Check out examples in the 'tests/index.test-d.ts' file and others when you have some time. Please let me know if you encounter any issues or have any ideas. Thank you! 😄

👉 https://github.com/didavid61202/type-level-regexp

@michaelschufi
Copy link
Author

HI @didavid61202
Thank you. I've got a lot on my plate right now, so it might take me a moment. But I'll try to have a look at it this weekend.

@michaelschufi
Copy link
Author

Sorry for my late response @didavid61202
I have tested the repo lately, and I couldn't find any breaking issue. I'm in awe of what this thing can do! 😍

Only one negative thing that I noticed: It seems to push either VS Code or the typescript language server to their limits. But this could be because of my pc, VS Code, TS, TLS, the repo itself with many complex examples, or any combination of those things...

I have a few minor things that I would like to discuss. E.g. what the restInput key represents. Should I file an issue in your repo?

@didavid61202
Copy link
Collaborator

Hi @michaelschufi, thanks!
Yes, I think this is pushing the language server to its limit by both lots of recursions and also lots of test examples. 😂 There are some performance issues that can be improved by a better parser and match algorithm. I've been testing some benchmark methods and I will start by rewriting the ParseRegExp generic. Any inputs regarding performance improvement are welcome!

Do file issues if you have any questions 👍
The restInput generic argument in RegExpMatchResult represents the rest of input string that is not matched by the regexp provided, it's used for resolving the preceding string before the matching string, and getting the preceding string length for index value of the match result.

@michaelschufi
Copy link
Author

Hi @didavid61202
About performance:
I've just read about the TypeScript 5.1 Beta's release notes and came across the Negative Case Checks for Union Literals section. Maybe those optimizations also affect the regex type literals.

@didavid61202
Copy link
Collaborator

Hi @michaelschufi, thanks for the info! 👍
I'll have to check if this affect the current implementation, or how we can utilize this to improve the performance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants