prisma-labs/graphql-framework-experiment

Code-First Type-Safe GraphQL Framework

graphql-framework-experiment's Issues

PUMPKINS_TYPEGEN environment variable

Problem

We need a way to run the app for just its typegen.

Solution

We can build in support for an ENV VAR that changes how pumpkins runs.

When PUMPKINS_TYPEGEN='true' then pumpkins will exit 0 after nexus typegen has run.

If is PUMPKINS_TYPEGEN specified (process.env.PUMPKINS_TYPEGEN !== undefined) but its value is not in "true" | "false" then raise a runtime error.

Example

PUMPKINS_TYPEGEN='true'

const app = createApp() // process exits before this returns
app.startServer()       // never runs

Notes

Related #3

optimize perf/dx around file watcher settings

Currently we ignore node_modules and watch everything else in the project for changes. This is probably not optimal and will not scale/be good both in terms of performance and in terms of dx.

hide build output in node_modules

#47 (comment)

To further underscore the high-level-ness of project dir, I was thinking of outputting the build to node_modules/.build (.pumpkins_build pumpkins_app_build, ...?) and then revisiting the idea of $ pumpkins boot which 1) knows to look into node_modules/.build and 2) knows to call the start module $node node_modules/.pumpkins_app_build/start

This helps because:

1. less things to gitignore
2. less generated things to think about. Closer to the interpreted spirit of JavaScript. There is a relaxing fact that a build folder will never have to be seen (generally) in a JS based node codebase. It's just simpler. We can get a bit of that feeling back by tucking away the build folder.

After this feature, we will need support from the CLI to make it easy to boot the app. While convention node_modules/.build/start is easy enough to remember, we can lower the bar further.

dev mode features leaking into build

turn off SDL artifact generation by default

on build tell user where build was output to

build command mvp

Needs #10

Problem

Users must apply a specific combination of tools and configurations thereof to successfully build their app "the nexus way".

For example:

• Have the right two env vars in place
• Use ts-node
• Pass ts-node the right flags (--transpile-only)
• Ex: user not realizing they need special env var to trigger typegen on heroku deploy

Spec

At a high level:

• Run Nexus typegen
• Then run a real TS build

In Detail

• Assume that entrypoint is src/server.ts

• Set environment variable PUMPKINS_TYPEGEN='true'

• there should be an entrypoint flag for running typegen

• if user provides nexus entrypoint config in package json and user does not pass entrypoint cli flag then use the package json variant

• Use the Compiler API to find the user's tsconfig.json and honour it

• peer dep on typescript, using a range as wide as possible

We may want to use https://github.com/davidtheclark/cosmiconfig

• if no json config is found and no cli flag is passed then fallback to the following lookups:

src/schema/index.ts
src/schema.ts
src/server.ts
src/main.ts
src/index.ts
schema/index.ts
schema.ts
server.ts
main.ts
index.ts
ERROR (please pass entrypoint)

Some original build design started in #272 (comment) and original cli work began in #275.

Scaffold

Setup the project:

• jest
• oclif
• typescript
• minimal test
• publish working CLI as 0.1.0-next.1

Start with version and help commands + flags.

Define Principals

Defining principals for pumpkins will help clarify for us how to make optimal tradeoffs. It will also give users better transparency into if the tool aligns with their needs/wants, and what they can expect out of the project mid/long-term.

During our brainstorming we sketched various sounds-good-maybe-maybe-not principals.

This issue is to take the next pass(es) distilling toward the essence.

I think we should limit ourselves on the principals we take on. Three? The goal is to simplify as much as we can tradeoff flashpoints, reduce the number of things we should be aiming to satisfy. In some ways more principals means owning more complexity, e.g. something akin to this:

Show Big Image

We can treat the following as a living document. As we discuss and revise, we can re-edit the following to stay up to date.

---

Principals

1. Its just an API

As much as possible users should be working with code. Activities like fiddling with the file system, navigating docs, writing deploy scripts, checking terminals, and more is energy lost. Our job is to provide an API where the leverage of every line of code is as high as it can be for the developer. The less time users have to pend outside TypeScript files the better.

2. Declarative Code Visualized

We leverage declarative APIs for CRUD, field projection, auth, and more to produce schematic overviews of the application. By doing this we make it easier to onboard collaborators and understand your architecture. We are paying back the user for using our API, aka. we are giving them leverage.

3. Generated What?

Generated artifacts are invisible to the developer

Example Applications

1. The user does not need to manage Photon.JS
   • think about declaring Photon.JS in their PSL
   • think about what output path to use for Photon.JS
2. The user does not need to mange nexus typegen
   • think about when to turn it on or off
   • think about what path to output it to
   • incorporate its existence into your mental model (it is sufficient to understand we provide TypeScript type reflection on steroids)
   • think about if it should be a declaration file (.d.ts) or just regular TypeScript file (.ts)
   • think about how it should be imported into your project (@types, import ... from ..., ...)

Other Detail

We have a significant amount of user non-success with the nexus and nexus-prisma workflow. We want our framework to allow users to never have to think about:

1. That there are generated artifacts
2. That there are generated artifacts in nexus-prisma that depend on generated artifacts from prisma
3. That the nexus generated artifacts are produced by the same app which uses them to get typechecked, and that failure in the latter never blocks from building/updating the former (otherwise chicken/egg).
4. Doing special things for deploying to Heroku, zeit, and so on.

We are aggregating user DX frustration about this issue here.

4. Zero Config

...

5. Smart Sherpa Not Static Guides

Instead of static guides that require the user to build a delta from their current position to we should move guides to the front lines. Think $ <thing> doctor on steroids.

$ <thing> what do I do next?

• "it looks like you aren't setup for deployment ..."
• "it looks like you haven't set up any graphql types yet ... "
• "it looks like you haven't setup your PSL yet ... "
• "it looks like you you haven't mapped X object at all ... "

5. Cake Before Cup Cakes

We start with ideal developer experiences. We avoid premature modularization. When in doubt, we do not modularize. We value finding natural wholistic seams over time.

6. Top Down Idealized Design

We envision our ideal developer experience and then work backwards to where we are.

7. We Expose It We Own It

Anything we expose our users to (cli commands, config, api exports, ...) we take responsibility for owning the mental model and approachability for. We are not a disjointed bag of features that users piece together a mental model for themselves by traversing half a dozen different docs. If we re-export nexus core building blocks but the docs for those building blocks are poor or cumbersome to access from our framework docs then we take it upon ourselves to resolve that (be it upstream contributions, creating our own docs, etc.).

8. Never Leave Your Development Flow

...

More literate start module

We should have a nicer start module that reads cleanly, for example in the following output there were no schema modules yet the comment just blindly goes on about importing them all. Simply confusing.

init command

We bake a lot of patterns into our examples. We can bring these patterns closer to users with an init command. It could:

• Setup suggested npm scripts
• Setup folder structure/tools/deps/scripts for deployment targets (heroku, zeit, ...)
• Setup prisma integration
• Setup suggest tsconfig
• post install hook running generate

We don't want to invest too much into this, probably. Scaffolding just automates what we couldn't figure out how to abstract in libraries or frameworks. I would rather focus on that. Still some basic scaffolding is a nice thing to help users get going.

Inspiration? https://github.com/yeoman/yo and prisma init?

use "graphql" term for examples over schema

Suggested by @schickling

Automatically run Photon delegates

Newer versions of Photon.JS introduce a delegate API. See this issue for an example difference between before and after prisma/prisma-client-js#290.

pumpkins is in a position to handle this better. Simply, it can add resolver middleware that will .then() photon delegates returned in a resolver.

(Note: maybe we can push the solution down the stack but anyways we'll start here.)

Before:

    t.field('blog', {
      type: 'Blog',
      args: {
        id: intArg({ required: true }),
      },
      resolve(_root, args, ctx) {
        return ctx.photon.blogs
          .findOne({
            where: {
              id: args.id,
            },
          })
          .then()
      },
    })

After:

    t.field('blog', {
      type: 'Blog',
      args: {
        id: intArg({ required: true }),
      },
      resolve(_root, args, ctx) {
        return ctx.photon.blogs.findOne({
          where: {
            id: args.id,
          },
        })
      },
    })

give user feedback when watch mode is restarting runner

generate command

The goal, is users can:

• trigger typegen
• trigger graphql schema gen
• control the output paths
• use their code configured outputs paths
• use their code configured outputs enabled/disabled
• use nexus defaults outputs paths
• use nexus defaults outputs enabled/disabled

Example of prior art on how a nexus generate command could look.

We may also want to consider breaking the generate command into two:

nexus typegen
nexus schema
nexus generate-schema
nexus generate-typegen
...

etc. but not sure.

Scalable, strongly typed GraphQL schema development

VERSION
  nexus/0.0.0-pr.275.004e62d darwin-x64 node-v12.12.0

USAGE
  $ nexus [COMMAND]

COMMANDS
  generate  Generate Nexus artifacts. By default your config.outputs settings will be used but you can
            override per output type via the respective flag.

❯ node bin/run generate --help
Generate Nexus artifacts. By default your config.outputs settings will be used but you can override per output type via the respective flag.

USAGE
  $ nexus generate

OPTIONS
  -e, --entrypoint=path
      Path to your app's TypeScript module that will run directly or indirectly Nexus.makeSchema. By
      default the following paths will be searched, picking the first match, or erroring out

          * src/schema/index.ts
          * src/schema.ts
          * src/server.ts
          * src/main.ts
          * src/index.ts

          * schema/index.ts
          * schema.ts
          * server.ts
          * main.ts
          * index.ts

            ERROR

  -g, --output-graphql-schema=path | 'true' (alias: 'default')
      If and where to generate the GraphQL schema as a file in SDL form. Useful for debugging or teams
      desiring SDL in their peer review process.

  -t, --output-typescript-types=path | 'true' (alias: 'default')
      If and where to generate the derived TypeScript types (aka. typegen). Useful for providing
      autocompletion and type safety across all your definition blocks and resolvers.

ALIASES
  $ nexus tg

revisit child hook module system

We currently have a large part of the ts-node-dev codebase effectively disabled because we are not using the child hook module system. The complexity of this sub-system has something to do with TSC compilation perf at scale, IIRC. While things are functional as-is we should revisit this topic. We are not deleting the code yet, just commenting out.

Lint for missing tsconfig

https://prisma-company.slack.com/archives/C8AKVD5HU/p1574776866323200?thread_ts=1574775264.320300&cid=C8AKVD5HU

when empty schema, use pumpkins default instead of nexus default

If restartRunner is spammed, we get EPIPE error

related https://stackoverflow.com/questions/37138044/child-process-throw-an-error-write-epipe

rename dist folder to build

dist is a folder name that makes sense for libraries or other tool-y things that will be "distributed". Pumpkins is for apps, and should be outputting a build to a build folder that will be deployed.

cache aware dot-pumpkins file writes

Currently we run into issues like this because our dot-pumpkins files are written blindly. We can prevent this from happening by comparing mtimes + hashed values.

Ignoring dot-pumpkins files is suboptimal because it means the dev workflow doesn't play well with it, which users may find surprising.

Seamless init to dev workflow transition

integrate heroku deployment

Not 100% clear what this will mean. Requires some research to understand all the things we can do to make deployment to heroku as easy as possible.

At a minimum it is documentation.

app reference modes

Not all users will want to work with a global singleton. We don't even know all the use-cases yet. How a large-scale app will look/feel. How testing will look/feel. However it is a great mode for certain scenarios, like a prototype or experiment, at least. It allows the DX to be that much closer to a DSL, some kind of purpose-built environment.

We have a spectrum of workflow modes to play with:

Declarative/Simple                                      Imperative/Flexible

global singleton --------- exported singleton --------- exported constructors

Let's explore each mode

global singleton

• schema type funcs are globally available
• schema type funcs are not importable
• schema type funcs are aliases to app.schema.*
• app is globally available
• app is a singleton
• app is not importable

objectType({
  name: "User",
  defintion(t) {
    t.id('id')
  }
})

Pros

• Domain Specific, business logic focused
• terse
• magic feeling

Cons

• Not conventional JS (whatever that means...)
• autocomplete on schema type funcs requires e.g. typing app.schema. to see intellisense. Schema func types can of course still be autocompleted but b/c they are global there is no organizing root parent property to filter for them as a menu (without, again, doing app.schema.).

exported singleton

• app is importable as named export from pumpkins
• app is a singleton

import { app } from 'pumpkins'

app.objectType({
  name: "User",
  defintion(t) {
    t.id('id')
  }
})

Pros

• combines some of the good aspects of either extreme...
• A) like global singleton, still pretty terse, because threading schema types is not needed
• B) like explicit, predictable discovery mechanism via imports

Cons

• taking singleton off global is an emotional appeal, the fact that its a singleton is the major engineering tradeoff, and that still applies in this approach. This mode may be a good starting point but it probably will not appeal to users once they get acquainted with pumpkins––either they will go full explicit or go global, presumably.

exported constructors

• schema type funcs are importable
• schema type funcs are pure
• app does not exist

import { createApp, objectType } from 'pumpkins'

const User = objectType({
  name: 'User',
  defintion(t) {
    t.id('id')
  }
})

const app = createApp()
const app.addTypes(User)

Pros

• Conventional JS (whatever that means...)
• Flexible (...use case?)
• predictable discovery mechanism (import package, autocomplete on exported members)

Cons

• Imperative
• Verbose

Execution Strategy

First an important principal:

• Every mode should feel first-class without any hint of compromise to the other modes being possible. In other words when in a mode, it should feel the library was built for just that mode.

Constraints:

• to achieve our principal means having optimized autocomplete. Having optimized autocomplete means codegen that "physically" changes the API surface of pumpkins.

• Codegen means we need to think about out of box experience; postinstall script hook has our back here.

• codegen means we need to think beyond the api surface, into higher order config land; package.json and ~/.config/pumpkuns. The former is project-local settings, while the latter is system wide settings (aka. changing the default).

Other:

• we need to pick a default 😬. I think exported constructors is a bad default, because its the maximum complexity option which users should grow into/choose, not be forced to start with out of the box.

  I think global singleton or singleton are eligible. @schickling has stated distaste for the former. But I'm not sure yet. I think we should get more feedback. If we take optional complexity into account, then starting from global singleton seems to be the right starting point, and user gradually opts into more complexity as they go.

🚲 🏠

Make dev command integrate with @prisma/lift

nextjs + prisma plugin recipe

What

• Demo app with both, how would that look like?

On new project, typegen is needed for singleton global to be accessible

tar required but we do not use it

For example in a project using pumpkins today:

❯ yarn pumpkins dev
yarn run v1.19.1
$ /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/.bin/pumpkins dev
Error: Cannot find module 'tar'
Require stack:
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/@prisma/sdk/dist/getPackedPackage.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/@prisma/sdk/dist/index.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/pumpkins/dist/framework/plugins/prisma.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/pumpkins/dist/framework/plugins/index.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/pumpkins/dist/cli/commands/dev.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/@oclif/config/lib/plugin.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/@oclif/config/lib/config.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/@oclif/config/lib/index.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/@oclif/command/lib/command.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/@oclif/command/lib/index.js
- /Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/pumpkins/dist/cli/index.js
    at Object.<anonymous> (~/projects/prisma-labs/foobar/node_modules/@prisma/sdk/dist/getPackedPackage.js:19:31)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

But pumpkins does not use tar directly.

We can fix it for users now by including tar but real fix is probably somewhere else.

doctor should check that .pumpkins is git ignored

Problem

Users should ignore pumpkins dot folder, but may:

1. forget to do so
2. not know to do so
3. do it wrong (typo or so on)

Solution

1. If repo is using git
2. If repo does not have gitignore
3. Or if repo does have gitignore but not ignoring .pumpkins

Then

1. Tell the user what they should do and why
2. Offer to do it for them

build command should defuse dev mode

Depends on #3

Motivation proposed in #292

Spec:

• codegen process.env.NEXUS_CONFIG around the app entrypoint so that shouldGenerateArtifacts is hardcoded to false
• make it possible to opt out of this behaviour (e.g. --no-defuse-dev-mode)
• When performing the defuse, check for existing NEXUS_CONFIG and if found perform a merge. Ours should overwrite the shouldGenerateArtifacts option.

context builder api

error on build b/c of transient types-dep

Vanilla project:

❯ yarn -s pumpkins build
🎃  Generating Nexus artifacts ...
🎃  Compiling ...
Error: node_modules/pumpkins/dist/utils/log.d.ts:1:26 - error TS7016: Could not find a declaration file for module 'debug'. '/Users/jasonkuhrt/projects/prisma-labs/foobar/node_modules/debug/src/index.js' implicitly has an 'any' type.
  Try `npm install @types/debug` if it exists or add a new declaration (.d.ts) file containing `declare module 'debug';`
1 import createLogger from 'debug';
                           ~~~~~~~
    at Object.compile (~/projects/prisma-labs/foobar/node_modules/pumpkins/src/utils/tsc.ts:102:11)
    at Build.compileProject (~/projects/prisma-labs/foobar/node_modules/pumpkins/src/cli/commands/build.ts:66:5)
    at Build.run (~/projects/prisma-labs/foobar/node_modules/pumpkins/src/cli/commands/build.ts:40:47)
    at Build._run (~/projects/prisma-labs/foobar/node_modules/@oclif/command/lib/command.js:44:20)
    at Config.runCommand (~/projects/prisma-labs/foobar/node_modules/@oclif/config/lib/config.js:151:9)
    at Main.run (~/projects/prisma-labs/foobar/node_modules/@oclif/command/lib/main.js:21:9)
    at Main._run (~/projects/prisma-labs/foobar/node_modules/@oclif/command/lib/command.js:44:20)

Solution right now is to add ignore lib errors in tsconfig:

{
  "compilerOptions": {
    "skipLibCheck": true,
  }
}

Review Gatsby CLI dev for inspiration

dev-mode log-view static bar to know to toggle into ui view

App mvp

Problem

We need a place to encapsulate the bringing together of various application concerns. For example nexus makeSchema and apollo server launch.

Solution

We can have a class/class-like representation of App.

This will accumulate, probably, many features over time, so this issue is about the foundation, and making sure it can more or less support the kind of things we can expect to more or less want to be doing in the near future.

type createApp = (options:AppOptions) => App

App {

}

...stub issue

Relationship to tsconfig

Had a meaty discussion with @Weakky on what our relationship to tsconfig is. It has some fields that we could:

• ignore

• rely on

• use if present, otherwise fallback

Examples include:

• compilerOptions.outDir

• compilerOptions.rootDir

• excludes

• includes

Things to keep in mind:

• JS users will not have tsconfig

• JS users will still have a build step because of, at least, start module that pumpkins codegens

• pumpkins is the top level concept, the more its config is distributed and inconsistent (e.g what TS calls rootDir pumpkins calls sourceDir, because pumpkins has the concept of projectDir which rootDir is too ambiguous a name to have as peer) and owned by unaware lower level tools the less power we have to tackle DX, more room for error, for bad combinations of settings, etc.

• pumpkins is a top level concept, having ways to configure it in tsconfig that JS users have to use package.json to configure just makes pumpkins projects more inconsistent, breaks the StackOverflow knowledge shareability, etc.

on build, clear previous if present

Otherwise build folders can end up with mixes of previous and current source folder structure/modules.

app modes

singleton
global
explicit

Do not force prisma to be used

All commands and APIs should work even if prisma is not present.

when running build, block on typegen

typegen in dev mode does not block the sever boot so that feedback latency is reduced. In build this is not good, as it means the server boots during typegen, leading to weird potential things like port in use errors if dev mode is running on the same machine etc.

To solve this we need to await typegen rather than doing in the background.

Warning when no photon generator block is defined + programmatically create one

https://prisma-company.slack.com/archives/C8AKVD5HU/p1574775324320400?thread_ts=1574775264.320300&cid=C8AKVD5HU

dev command

Today user needs to manage additional deps (ts-node-dev) and remember to use flags correctly (--tree-kill, --transpile-only). We should simplify this with a nexus dev command. In the future we can integrate optionally prisma dev seamlessly. Also in the future we could seamlessly support JS projects by just being a wrapper around e.g. nodemon.

Instead of doing spawns tsmon or ts-node let's try working with the TS compiler API directly? If there could be value in using ts-node as library or tsmorph library let's explore that too.

first version:

• TS focused
• low level implementation with TS compiler API if sensible

remove node-fetch types dev dep

Added just so that we can build:

Support JS

Instances

• graphql-nexus/nexus#1145

dist folder nesting

Given tsconfig:

{
  "compilerOptions": {
    "skipLibCheck": true,
    "rootDir": "app",
    "strict": true
  }
}

build leads to incorrect folder structure

❯ tree dist
dist
└── app
    ├── app.js
    ├── app__original__.js
    └── schema.js

There should be no app nesting there.

Adding files / folders doesn't get picked up without dev mode reboot

projected model fields whose type is missing in GQL schema scaffold prompt / workflow

Underlying nexus-prisma feature graphql-nexus/nexus-plugin-prisma#544

doctor command check for --types compiler option

Encode a doctor check for the --types gotchya #284.

• check the user's tsconfig (find it via the TS compiler API)
• if no types compiler option in use do nothing
• if types compiler option is in use and
• if the default typegen path is not in it and
• if package.json nexus doctor types compiler option warning is disabled do nothing
• then log warning

prisma dev integration

Problem

Prisma dev workflow requires user to enter into a different and less informed workflow.

Different workflow means user has to start a new terminal, use a different cli, interact with different styles/patterns of feedback be it status updates or error messages.

Less informed workflow means pumpkins knows more about the user's intent because pumpkins is the user's application framework. In contrast Prisma knows nothing about the app. So for example:

1. Prisma does not know what to or where to generate things while pumpkins does know. pumpkins knows that Photon should be generated and because it controls the consumption side of photon also therefore knows the path it should be generated at.

Solution

Use a Prisma SDK within the implementation of pumpkins to control Prisma during pumpkins dev.

Requirements

1. Be able to host studio ourselves

2. Be able to detect when a semantic change to PSL has occurred

3. Be able to programatically generate photon without its needing to be in schema.prisma

4. Be able to ask users to confirm a destructive database migration. This means an API that makes it easy to:

   1. Detect/be notified about a destructive change
   2. Have a structured representation of the destruction change (what it is, why it is, etc.) that would contain everything needed for rich rendering
   3. Rendering functions would be welcome, but getting the granularity right to enable generic utility like reuse is the challenge
   4. Cancel or go ahead with a migration based on user answer

5. Be able to easily extract PSL content, manipulate it, represent it (see example error message above)

Examples

We Host Studio

$ pumpkins dev

==> Good Morning! I'm launching your app now at http://localhost:3000

		Some stuff to checkout:

		/topology ..... Your app crud, mapping, and other topology
		/studio ....... The Prisma control plane for your data layer
		/playground ... The GraphQL Playground, make queries and see results
		/graphql ...... Standard schema introspection endpoint

We watch for meaningful changes to the PSL file
We regenerate photon when the PSL file changes
We migrate the dev database when the PSL file changes

==> Data Layer Change

	Hey I saw some changes in your data layer:

		1. A new Book model
		2. Three fields removed from User model

		+ model Book {
		+  id    Int
		+  title String
		+ }
		
		  model User {
		-  location   Location
		-  middleName String     
		-  lastActive DateTime
		   ...
		  }

	I'll propagate these changes for you now!
    
	    Regenerating your photon client...
		Migrating your database...

React to meaningful changes (example 2)

==> REBOOT (546ms)
--> SCAFFOLD OPTION

		Hey It looks like you added a new model Car to your PSL. Would you like
		to generate a GraphQL Car Object definition?

			objectType({
				name: "Car"
				definition(t) {
					t.model.model()
					t.model.year()
					t.model.make()
				}
			})
		
			>	Copy into your clipboard (c)
		     	Generate file            (f) /server/types/Car.ts

The user does not have to declare photon themselves

// What user has to write
// schema.prisma

model User {
  // ...
}

model Book {
  // ...
}

// What pumpkins takes care of
// User does NOT have to write this
// User does NOT see this

generator photonjs {
  provider = "photonjs"
  path = ".pumpkins/photon"
}

The user receives rich inline/in-context PSL content rendering so that we can do things like so:

==> REBOOT (145ms)
--> WARNING
		
		I found that some of your field projections do not have 
		corresponding prisma model fields:
		
		User Object @ types/User.ts
			
		120|  defintion(t) {
		121|    t.model.name()
		122|    t.model.role()
		   |            ~~~~ ---------------------
		123|  })                                 |
		124|                                     |
                                                 |
    API Layer                                    |
    --------------------------------------------------------------------------------
    Data Layer                                   |
                                                 |
    User Model @ prisma/schema.prisma            |
                                                 |
		130|  model User {                       |
 	    131|    address   String                 |
        132|    birthday  Date                   |
	    133|    friends   Friend[]               |
		134|    name      String                 |
           |     	      <------------- missing |
		135|    sex       Sex
		136|  }

when runner crashes due to app error, no feedback for developer

In the follow, the LOC that is underlined by the IDE, if commented out, dev mode will succeed up to server launch. If left as-is, runner crashes, but user gets no feedback about it. Not even if viewing debug logs (they just find out that the runner crashed).