How to extend a generator within another generator?

[Erazihel]

Hello there 👋

I'd like to extend the @nrwl/react:app generator in order to generate applications that perfectly match our needs inside our monorepo.

I'm currently importing the applicationGenerator method from @nrwl/react inside my generator. The thing is, in order to make it work, I have to duplicate a lot of content from the schema.json from the application generator.

I'd also like to know if updating the content of the generated file by the application generator is something feasible or not? I must say that the documentation on the Nx website is poor on that precise matter.

Thank you for your responses.

Cheers!

[Brian-McBride]

I was just about to ask something similar. I don't want to fork the entire @nrwl/node plugin, but I do want to build an executor that runs that first, then I can follow up with some of my own tasks.

One answer is to make a second generator/executor that you just run after. In your case you can generate the React app then build another generator (or possibly executor) to do more work and just target that project. Adding more steps to automation isn't great as that means more potential for human error. It is the short fix for now though I suppose.

[gioragutt]

https://github.com/gioragutt/nx-backend-e2e/blob/main/libs/soluto-e2e/src/generators/e2e-project/generator.ts

Here you can see an example of how a generator would use another generator.
After the generator is done, you can do whatever you want in the Tree, including changing previously generated files.

The schema.json problem is real, but there's no real workaround for that currently.

For learning more about generators/executors implementations, I suggest you go through the code in the official NX plugins, you'll see a lot of examples of what can be done.

[Brian-McBride]

@gioragutt Does this work for executors too?

Is there a plugin that you might know of that extends the @nrwl/node build process by pre/post additions?

[gioragutt]

Executors are eventually just functions as well. Invoking them is a little harder, but very much doable.

I think that my best suggestion, in this case, is to read and study the source code of existing plugins, whether it be the official ones or not.
You'll see a bunch of examples of different executors and what they do. This is how I learned most of my NX knowledge.

[Jedliu]

@gioragutt Thanks for your reply! This helps me a lot.

[rfprod]

The following solution is not perfect, but maybe it helps https://github.com/rfprod/nx-ng-starter/tree/main/tools/generators/client-feature - this is how a custom client feature library can be generated.
It is based on 4 generators. It generates files based on custom templates.
Disregard that it's for Angular. I think the same can be implemented for any framework.

[shanky101]

I'm in the same boat as @Erazihel.
For anyone stepping into nx ecosystem who need to create custom workflows, modifying default files generated by standard generators for popular libraries like React, Angular, node etc would be a pretty common use case.
The docs absolutely do not shed light on this. All the suggested answers here talk about going through source code of existing plugins which for new users to nx ecosystem is daunting and confusing to say the least.

Is there any documented way to extend react generator and modify the files? (I tried going through docs, videos but could not understand the way to achieve the same).

[ruscon]

Also faced with the problem of inheritance of standard generators.
If you generate a library by specifying the directory option, then the final project name is generated exactly in the normalizeOptions function.

Therefore, there are 3 options:

• Return normalized options (or at least the name of the created project) as a result of executing the main generator function. - IMHO the best way. Now it simply returns void, so from the point of view of business logic, it will not break anything for anyone. From the point of view of typing, it can be like a breaking change.
• At least add export for the normalizeOptions function, but, eventually, it will be called twice, and in theory, it can also lead to unpredictable behavior in the future if this function writes something somewhere.
• Copy the logic of thenormalizeOptions function, but it is irrational and may lead to bugs when upgrading to the next versions of nx

[kfern]

HI! I think this coukd help #5125 (comment)

Now to answer your question (assuming you want to call a real nx's generator from another one), I would say 2 things are needed to have this work:

your to-be-called generator method must be made public/exported (inside the index.ts of the generator's package)
its package.json must have a "generators" property that points to the generators.json declaring the generator (its implementation, schema, etc)

Then in your calling generator just do: await myBaseGenerator(tree, [options]) and you should be good to go!

[kfern]

This is a basic example of how to extend a custom generator with another generator

import { formatFiles, getProjects, Tree } from '@nx/devkit';
import { InitGeneratorSchema } from './schema';

import { libraryGenerator as angularLibraryGenerator } from '@nx/angular/generators';

export async function initGenerator(tree: Tree, options: InitGeneratorSchema) {
  const projects = getProjects(tree);

  if (!projects.has(options.name) {
    await angularLibraryGenerator(tree, {
      name: options.name,
    });
  }

  await formatFiles(tree);
}

export default initGenerator;

[R1D3R175]

In case it can help someone, I made a gist showing how to create a generator that extends @nx/angular:library; it also copies an Angular application ESLint config and pastes it in the library folder.