Idiomatic schematics for NestJS

Expected Behavior

It would be awesome if we could enhance the @nrwl/nest schematics to be more idiomatic to an Nx workspace, and support this syntax:

nx generate @nrwl/nest:<schematic> --project <project>.

Current Behavior

Currently we add @nestjs/schematics as a peer dependency and while that allows you to generate NestJS code, there are a few things with it.

Firstly, it doesn’t have the notion of projects, so in order to generate code in one of our libraries we need to pass in the full path, like so:

$ nx g @nestjs/schematics:service todo --sourceRoot libs/todo/src/lib 
CREATE libs/todo/src/lib/todo/todo.service.spec.ts (446 bytes)
CREATE libs/todo/src/lib/todo/todo.service.ts (88 bytes)
UPDATE libs/todo/src/lib/todo.module.ts (194 bytes)

I would love to be able to just to nx g @nrwl/nest:service --project todo - similar to for instance @nrwl/angular or @nrwl/react.

Additionally, @nestjs/schematics has a couple of schematics that don’t really make sense in the context of a Nx Workspace:

• angular-app
• application
• configuration
• library
• sub-app

Context

To start, I think it makes sense to port over some of the schematics that are most frequently used (at least by me that is, your milage may vary).

• controller
• module
• resolver
• service

These are some other schematics from @nestjs/schematics that might be good to port at some point:

• class
• decorator
• filter
• gateway
• guard
• interceptor
• interface
• middleware
• pipe
• provider

Lastly, I’d love to add a schematic that allows configuring GraphQL in a nest module. So nx g @nrwl/nest:graphql --project api would install and configure @nestjs/graphql in the api project.

Other

I’m opening this issue to see if it makes sense to add this. If so, I’d be happy to create a PR that adds the first 4 schematics I listed above, and later optionally ad some more.

Also, as I see myself using these schematics quite a bit in the future, I’m happy to take on maintaining these schematics inside nrwl/nx for the foreseeable future.

[yharaskrik]

@beeman sounds great. Send me a message in the slack channel?

[Cammisuli]

Hi @beeman, we need to think of a way to dynamically map all the nest schematics to support the --project flag. Currently we would have to do what you suggested and have a one to one mapping between nest and nrwl. And there’s a lot. It’ll be a big maintenance burden ☹️

This is something that we need to talk about more for sure.

In the meantime, you can create workspace schematics that map the ones you need for your repo.

As for the graphql one, you’re more than welcomed to add support for that 😄 . If you need help with it, you can reach out and I’ll be more than happy to help you.