Roman

This GH Action fails: https://github.com/moltar/projen-graphql-codegen/blob/9a0ccf85836dc8dc1282955363acd106a40b07fd/.github/workflows/release.yml#L18-L39 With: ``` 👾 release » build » default | ts-node --project tsconfig.dev.json .projenrc.ts yarn install v1.22.17 [1/4] Resolving packages... success Already up-to-date. Done in 1.89s....

Switched to using NPM - same issue :/

Pinning to `[email protected]` seems to have worked 🤷🏼

> This is an opinionated feature, which depends on the workflows. Makes sense. Maybe then additional configurable footer prompts could be a more abstracted feature. E.g. allow user to define...

I think the original issue asks about babel, which seems to be still an issue. E.g. when using `parcel`, get the same errors: ``` 🚨 /.../node_modules/pg/lib/native/client.js:11:21: Cannot resolve dependency 'pg-native'...

Here's a working solution. Obviously needs some refactoring, but it's a good start. This also uses `@accounts/typeorm`, which is optional, of course. ```ts import { Module } from '@nestjs/common'; import...

The only thing I am unhappy about is this: ```ts const typeDefs = print(accounts.typeDefs.definitions); ``` The `@nestjs/graphql` module expects `typeDefs` to be a string, but `accounts.typeDefs` is a `DocumentNode` type....

I think we could refactor the project to work with pluggable providers. A provider interface will provide an array of migrations. How this provider gets those migrations is up to...

> What would be the benefit of that? Of which part of my proposal?

Benefits: - End users are able to implement their own providers, e.g. `*.sql`, if the core does not want to support it - Decouples runner from the obtainment of migrations,...