0.0.4 • Published 4 years ago

pirs v0.0.4

Weekly downloads
-
License
MIT
Repository
-
Last release
4 years ago

PIRS: prisma-introspect-renamer-saver

npm.io

PIRS (prisma-introspect-renamer-saver) transforms a .prisma file to apply a set of diffs on the generated data model. This automates the mapping that may have to be done after each time $ prisma introspect is run to make it fit the naming conventions.

Install

$ yarn add --dev pirs

Usage

$ yarn pirs -p schema.prisma -t transforms.yaml --write

(See yarn pirs --help for more options.)

Motivation

The generated Prisma data model (the .prisma file) that may not confirm to the Prisma data model conventions, so it is encouraged to edit the file accordingly.

Howver according to the Prisma's docs:

Warning:

Prisma-level relation fields that were renamed in the Prisma schema will be reset when you run prisma introspect again. You therefore might want to back up your Prisma schema with these attributes in order to not having to annotate everything from scratch again after a re-introspection.

It seems as though any artisanally hand crafted changes you make to the generated .prisma file will get blown away each time you run $ prisma introspect after an SQL Schema change.

pirs addresses this by allowing you to declare the diffs you want to apply in a YAML file. After each time $ prisma introspect is run, we can now run $ yarn pirs to magically rename the fields, without having to do it by hand all over again. (Think of this as a fancy patch file).

Example

Consider the following sample schema.prisma file:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id           String        @id
  created      DateTime      @default(now())
  name         String?
  email        String        @unique
  passwordHash String
  UserSession  UserSession[]
  Photo        Photo[]
}

model UserSession {
  token   String   @id
  created DateTime @default(now())
  userId  String
  User    User     @relation(fields: [userId], references: [id])
}

model Photo {
  id             String  @id
  title          String?
  url            String
  userUploadedId String
  User           User    @relation(fields: [userUploadedId], references: [id])
}

In accordance with the naming conventions, we'd probably want to transform:

  • User.UserSession -> User.sessions
  • User.Photo -> User.uploadedPhotos
  • UserSession.User -> UserSession.user
  • Photo.User -> Photo.uploadedBy

Applying the following transforms.yaml file lets us do just that:

models:
    - name: User
      fields:
          - field: UserSession
            attributes:
                fieldName: sessions
          - field: Photo
            attributes:
                fieldName: uploadedPhotos

    - name: UserSession
      fields:
          - field: User
            attributes:
                fieldName: user

    - name: Photo
      fields:
          - field: User
            attributes:
                fieldName: uploadedBy

See the tests to see this in action.

API

Currently, we only support rewriting the field names on models.

The --transformsFile (or -t) arg must point to a yaml file in the following format:

interface Transforms {
    models: Array<{
        name: string;
        fields: Array<{
            field: string;
            attributes: {
                fieldName?: string;
            };
        }>;
    }>;
}

FAQs

Why not use \?

I googled and didn't find any other lightweight solutions that that did this. But maybe I missed something! I figure if it does exist, the best way to find out is to publish this and have people let me know about it :)

I want this to work with \?

If there's a feature missing that you think should be added - open up an issue! Even better, PRs are super welcome too :)

Why is this code so janky?

I'd love to do a fancy AST transformation, but I didn't fancy writing my own parser :p

Is this over-engineered? This seems over-engineered.

Probably. Let me know what you think in a GitHub issue / on Twitter, and what you'd suggest instead!

Contact

0.0.4

4 years ago

0.0.3

4 years ago

0.0.2

4 years ago

0.0.1

4 years ago