-
Notifications
You must be signed in to change notification settings - Fork 2k
refactor: treeshakable kind enum #4270
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
refactor: treeshakable kind enum #4270
Conversation
Duplicate of #4268. |
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@JoviDeCroock needed to focus on other things so #4268 was closed. I am re-opening this PR therefore to finish that work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to take this approach for all enums?
Yeah I think there's nothing to lose by doing that and it would be a better DX (e.g. all enum have type level name spaces, consistent) plus be tree-shakable. If you agree then I can update this PR to change them all. |
@cvbedc Unknown command 😕 Supported commandsPlease post this commands in separate comments and only one per comment:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the odds of other enums tree-shaking is a lot lower and the amount of code we add in this approach is quite high. The others like DirectiveLocation, ... are more geared for server-side code either way. I don't merging as is as the bundle impact is reduced by moving off of TS enums
Right now I don't have a strong preference. I consider the type level symmetry aspect bike shedding territory. Happy to throw my labour at this so no issue there. If this PR generally looks shippable as is, that's great! |
closes #4253