-
Notifications
You must be signed in to change notification settings - Fork 2k
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
refactor: treeshakable kind enum #4270
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