support autofixing problems

[iiian]

Hey guys!

I currently "maintain" a repo called prisma-case-format, and I'd like not to, so I'm soliciting you guys to implement some of my scope. I initially started that tool as a way to do one-time "introspection cleanups" for fresh prisma projects using existing database schemas, but more and more my users have asked for features that I would consider to be more "linterish".

It looks like the ambitions of your project could potentially be a superset of my project's functionality, so if you guys implement issue autofixing in prisma-lint, I can deprecate my repo and direct my users to yours instead!

The current scope of functionality I support is:

• Allowing users to specify "case-conventions" on model/view/field/enums: PascalCase, snake_case and camelCase.
• Allowing users to specify "plurality" for model/view/field/enums: For example, our database team said that we're going to use singular (user not users) conventions, but our team wants to use plural model names (Users, not User).
• Using the above to specify two separate sets of case conventions: one for the actual database, and one for the generated models. For example, our database team wants everything in our models to be snake_case because Postgres, for instance. By contrast, our team wants to do model names in PascalCase and field names in camelCase.
• Allowing users to capture specific name deviations: For example, our team inherited a database with semi-wonky names like PK_ID @id Int, that we'd like to massage to be id Int @id @map("PK_ID").
• Support for next-auth, which probably isn't that important to support explicitly as long as you support lint rules that can vary per model or per field.

I've got an extensive set of test cases if it matters.

Thanks, and happy new year!

[maxh]

Thanks for reporting. Cool project.

Indeed, autofixing seems within the scope of prisma-lint and has been in the back of my mind for a few months. It's not something our team needs at the moment, but I'm considering it as a side project, or supporting anyone else interested.

At first glance, taking inspiration from prisma-case-format, perhaps we could have overarching rules like:

• require-case-convention (no existing rules)
• require-map-case-convention (would subsume existing model/field-name-mapping-snake-case rules)
• require-grammatical-number (would subsume existing model-name-grammatical-number rule)

For which the config objects allow specifying separate preferences for model, view, field, enum. Or perhaps configuration and implementation would be easier to manage with separate rules for each.

The specific name deviations could be handled either with in-schema comments or additional configuration options. I'm not familiar with next-auth.

In terms of apply fixes and generating source code, I believe the parser currently used has some affordances along those lines: https://github.com/MrLeebo/prisma-ast

Overall this seems doable and your project serves as good inspiration.