-
Notifications
You must be signed in to change notification settings - Fork 13
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
feat(core): run prettier on codegenerated files #100
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@cstrnt is attempting to deploy a commit to the Stellate Team on Vercel. A member of the Team first needs to authorize it. |
@@ -96,6 +96,9 @@ async function boostrapCodegen(port: number, path: string) { | |||
baseDirectory + '/**/*.{ts,tsx}', | |||
baseDirectory + '/types/**/*.ts', | |||
], | |||
hooks: { | |||
afterOneFileWrite: ['prettier --write'], |
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.
This is going to crash if prettier
does not exist, no? Also for performance reasons, this would be better after all the files have been written I reckon.
We have to either see whether the user has this installed in their workspace-root, workspace-folder or we give them an option on the plugin
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.
- Yes, you're right. It will in fact crash
- The docs state that
afterOneFileWrite
is the recommend way since it's only run for a single file when that changes - I'm pretty sure that prettier resolves this by default for themselves
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'm pretty sure that prettier resolves this by default for themselves
That's not what I'm saying, this point connects to 1, where either we introduce this as an option where the user has to opt-in voluntarily or we detect prettier. The reasoning here is that a lot of folks might just check this into their .prettierignore
or might not have gotten prettier installed in the first place. The presence of prettier
and by extension the willingness to subject generated files to these rules shouldn't be a strict opinion to code-generation working.
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.
Okay that makes sense. Detecting prettier doesn't seem that trivial since it could be either
- installed globally (easiest)
- Installed in the current package
- Installed in the workspace root
But even if we decide to add an option here we still need to figure out how to run the prettier binary since this changes depending on the setup
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 this is what you meant
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.
The running of it doesn't change depending on setup tbh, just prettier is enough if they enable it imho
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 have two ideas right now. We could either:
- Give the user the option to add the hooks themselves (my preferred option; would allow them to run their linter as well. Not only prettier.)
- Just pass in a flag which will run prettier.
What do you think?
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.
We could give them the option, there are a few places where we manually write files through fs
but those are one-time writes so we could just stop writing when they are already in the filesystem so it is only a one time git diff for the user.
Fixes #93 . This also enables the codegen in the next at all. The files weren't created at all