graphql-nexus/nexus-prisma

Avoid pruning issues of generated code in node_modules/.nexus-prisma

jasonkuhrt opened this issue ยท 6 comments

What

  • Outputting into node_modules in a hole in the package installations is subject to package pruning. Prisma Client had this issue for example.

Why

  • Annoying for users

How

@Jolg42 @millsp Am I correct that that NP should be doing it how PC does? Thing is we've been using NP for months and haven't had an issue with current approach. We use Yarn 1 on PDP CP codebase.

Yes, and the @prisma/client/index.js does https://unpkg.com/browse/@prisma/client@3.6.0/index.js

const prisma = require('.prisma/client/index')

module.exports = prisma

index.d.ts

export * from '.prisma/client'

One downside of this, that you might have currently too is that changes in the generated client are not picked up instantly by the TypeScript Server in VS Code which is why the Prisma extension https://github.com/prisma/language-tools has a watcher and restarts the TS Server if it detects a change.
What's the status on that here @jasonkuhrt?

@Jolg42 NP outputs the runtime into, for example, node_modules/nexus-prisma/dist-cjs/runtime/index.js.

I have not noticed pruning issues, or seen user reports about that either.

The pruning might be related to the postinstall generate for Prisma Client, but you don't use a postinstall here?

Also behaviour is often different between the package managers.

What about this part? Do you have this problem in VS Code as well now? If not, it's possible it will be a thing after changing the output to dot folder and if it's the case, I'm curious to know.

changes in the generated client are not picked up instantly by the TypeScript Server in VS Code which is why the Prisma extension prisma/language-tools has a watcher and restarts the TS Server if it detects a change.

@Jolg42 let's jump on a call sometime and investigate this interactively if we're really curious :)

Might be a good TS group meeting agenda item?

We fixed it in #219