Add --map-field-case / --map-table-case option about prisma-case-format HOT 5 CLOSED

Hey @marklawlor , glad you found the tool useful.

Can you describe your workflow for me? How are new properties being generated, and why is it infeasible to keep them in sync by hand after the initial migration?

If I understand correctly, it sounds like you're asking for "don't bother applying conventions if the table or field already has a map annotation applied.

I'm a bit swamped at work right now, so it could be awhile before I get around to it, but if you wanted to create a PR for this, I would happily merge it in because making the tool idempotent is a reasonable idea.

from prisma-case-format.

Can you describe your workflow for me? How are new properties being generated, and why is it infeasible to keep them in sync by hand after the initial migration?

We would like to keep our database in snake_case and JS in camelCase/PascalCase for legacy and stylist reasons. It's not infeasible to maintain by hand, and we have been doing so for quite a while - however someone evitiable forgets to add a @map() and accidently pushes a camelCase column.

Prisma has no linting tool, so we rely on PRs to catch human error but mistakes happen. I would like to use this CLI in our CI pipeline:

• On PR creation run prisma-case-format
• If the CLI changes the schema we can fail the PR as a column and/or @map() value is missing.

If I understand correctly, it sounds like you're asking for "don't bother applying conventions if the table or field already has a map annotation applied.

No. I would like a flag to also apply a case convention to the @map() attribute. If a @map() is missing (and the generated column will be in the wrong case) it should add a @map() attribute OR if the @Map() is incorrect, it should be updated to the correct case.

from prisma-case-format.

Gotcha. Thanks for correcting me there. I see now that --map-[field|table]-case= are new properties you're proposing. I had not considered using this tool as a small "aftermarket" CI for prisma schemas, but I see the value in what you're proposing.

I probably have time to get around to it in the next few weeks, either when work calms down or the mood strikes.

You could use --dry-run to diff the changes against your schema, or I could add a --check or --detect-drift flag that yields a number of validations to stderr.

from prisma-case-format.

@marklawlor, I've pushed out [email protected] which corresponds to this pull request.

Per your suggestion, you can get ongoing convention-drift-checking by calling

prisma-case-format \
  --file=<du jour> \
  --dry-run \
  --field-case=<du jour> \
  --table-case=<du jour> \
  --map-field-case=snake \
  --map-table-case=snake

I teed up quite a few tests to make sure everything is on the up and up, but it would be great if you could pull this beta version and run it on your setup, even just once, to see if you can spot any obvious bugs.

from prisma-case-format.

That works really well 👍

from prisma-case-format.