Importing a Prisma schema

Importing a Prisma schema prisma:import converts a schema.prisma into Prorm model files plus one initial migration. It is a pure translation — it reads a schema file and writes source; it never connects to a database, and it never runs a migration. Flag | Default | --- | --- | --schema <path> | ./schema.prisma | --models-out <path> | ./models | --migrations-out <path> | ./migrations | What lands on disk: one <Model>.ts per Prisma model block, using the decorator API, a models/index.ts barrel exporting every model plus a registerModels(prorm) helper, <timestamp>-prisma-import.js — a single "initial schema" migration covering every table and relation. As a library The conversion is exported, so you can drive it yourself — in a codemod, a test, or your own tooling: parsePrismaSchema(source) gives the parsed PrismaSchema (models, enums, fields) if you only want to inspect it, and resolveRelations(models, names) resolves the relation graph on its own. Nothing in this module touches the filesystem — the CLI owns reading and writing — which is why it is straightforward to unit test. Type mapping Prisma | Prorm | --- | --- | String | DataTypes.STRING(191) | Int | DataTypes.INTEGER() | BigInt | DataTypes.BIGINT() | Float | DataTypes.FLOAT() | Decimal | DataTypes.DECIMAL(65, 30) | Boolean | DataTypes.BOOLEAN() | DateTime | DataTypes.DATE() | Json | DataTypes.JSON() | Bytes | DataTypes.BLOB() | an enum block | DataTypes.ENUM('a', 'b', …) | String maps to 191 characters because that is the longest utf8mb4 column MySQL can index under the older 767-byte key limit. Widen it after import if your target does not have that constraint. What it refuses to convert The importer throws rather than guessing. Each of these stops the run with a message naming the model and field, and telling you what to change: Implicit many-to-many relations — both sides declared as plain arrays with no @relation. Add an explicit join model, which Prorm needs anyway for belongsToMany. A relation with no owning side — neither side declares @relation(fields: [...], references: [...]), so nothing says which table holds the foreign key. Composite foreign keys — a relation referencing more than one column. An unmapped scalar type — anything outside the table above. The error lists the scalars it does support. That is deliberate: a silently mis-converted relation surfaces as data corruption weeks later, while a failed import surfaces now, with a fix in the message. After the import The generated output is a starting point. Before you run the migration: 1. Read the migration. It is the whole schema in one file; make sure it matches the database you actually have (or intend to have). 2. Check the types. String(191), Decimal(65,30) and DATE are reasonable defaults, not necessarily your column definitions. 3. Add what Prisma does not express — hooks, scopes, validations, paranoid, and any index Prisma held in a @@index that you want tuned. 4. Diff against the live database with SchemaDiffer if the schema already exists, rather than running the initial migration over it. Register the models the barrel file gives you: Related reading CLI Defining models, Decorators Associations Migrations, Schema diffing