Add --map-field-case / --map-table-case option

[marklawlor]

Describe your request

This library does a great job at a one time conversion, however I would like to use it to maintain consistency within my schema.

For example, say I want to maintain pascalCase for columns, but always map them to snake.

model Account {
  id             String  @id @default(cuid())
  userId         String
  firstName      String? @map("first_name") @db.Text
}

If you run prisma-case-format nothing will change

Proposed behaviour

With the --map-field-case=snake --map-table-case=snake flags, the schema will change. Now it is checking that each column correctly maps to the desired case.

model Account {
  id             String  @id @default(cuid())
  userId         String  @map("user_id")
  firstName      String? @map("first_name") @db.Text

  @@map("account")
}

Workarounds

I tried doing two conversions, eg converting to snake and then pascal, however this created duplicate @map on each column

[iiian]

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.

[marklawlor]

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.

[iiian]

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.

[iiian]

@marklawlor, I've pushed out prisma-case-format@1.3.0-beta.0 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.

[marklawlor]

That works really well 👍