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

feat: resolve Prettier config from file for payload generate:types cmd #11124

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

proto-cool
Copy link

What?

This PR extends the generateTypes.ts script to read from the appropriate prettier config in a user's Payload application (if one exists), so that the output of payload generate:types (payload-types.ts) respects the prettier configuration.

Why?

The payload-types.ts file that was generated by Payload was previously not respecting the prettier configuration when generated by payload generate:types. While not a major issue by any measure (i.e., there are workarounds, like formatting with commit hooks on downstream consumers of payload-types.ts, it is nice to have it respect the existing config if possible.

How?

I started with the prettier config resolution found in packages/drizzle/src/utilities/createSchemaGenerator.ts, but since I define my prettier with the key in package.json like the following:

"prettier": "./prettier.config.mjs"

The resolution of the actual config was not working quite correctly as I guess the standard prettier.resolveConfig() does not play nice with ESM module configs (maybe I'm doing something wrong in my repo with that config?)

Anyway, I stubbed it out into a function loadPrettierConfig() which does exactly that, otherwise returning the old default of just { singleQuote: true }.

Maybe the contents of loadPrettierConfig() needs adjustment, but overall this does function with my personal Payload project at respecting my prettier settings when exporting payload-types.ts, and the the dev:generate-types call seems to also respect changes to the config in the payload monorepo when testing, which I believe would be preferable.

Please let me know if you have any thoughts or questions!

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

Successfully merging this pull request may close these issues.

1 participant