document implicitDependencies vs dependsOn for nestjs-prisma recipe

[robert-king]

As a NX beginner it'd be nice to know if i should use dependsOn for this recipe, and also if I should add an output dir so that our team can get distributed task caching? (we have 50 or so schema.prisma files so caching would help, some of them take 5-10 seconds to generate for different architectures, and we all ways get cache miss obviously).

There are times when the app is affected, or needs to serve or build, but prisma generate hasn't been run, which will cause an error.

The nestjs-prisma recipe uses implicitDependencies for the schema lib since it does code generation, however, should we also consider using dependsOn relationships? Also, i'd like to see a comment in the readme about the relationships, why they're important to the recipe for those who are less familiar with NX.

An example of using depends on for my-apps build target would be:

"dependsOn": [ { "projects": ["my-app-schema"], "target": "prisma-generate" }, { "projects": ["my-app-analytics-schema"], "target": "prisma-generate" } ],

The issue this dependsOn solves is that otherwise people could build or serve the app and it would break if they forgot to generate. Also in CI/CD, since the node_modules is git ignored, generation is required. However the nx affected command doesn't re-generate the schema if it hasn't changed, even if the app requires it.

example links for reference:

https://github.com/nrwl/nx-recipes/blob/5bd23b05f6dda02fc2aeec0815ba13facf5a4251/nestjs-prisma/libs/prisma-schema-one/project.json#L13C4-L18C7

https://github.com/nrwl/nx-recipes/blob/5bd23b05f6dda02fc2aeec0815ba13facf5a4251/nestjs-prisma/libs/prisma-client-one/project.json#L23

"implicitDependencies": ["prisma-schema-one"]

[robert-king]

@isaacplmann i thought this could be relevant for you btw. also i'd like to know how prisma seed can use seed.ts which is like an extra entrypoint to some libs.

right now i'd have something like this in my seed.ts

// eslint-disable-next-line @nx/enforce-module-boundaries import { machineConfigs } from '../../../../../libs/xxx/src/lib/consts/machines'; // todo custom executor for seeding

instead of

import { machineConfigs } from '@thred/xxx'; // todo custom executor