[schematics] Compose-able Schematics

[matt328]

The nrwl schematics are a great start, and our organization would like to tailor them slightly to fit our needs. The first use case I'm working with is to automate the process where we first run a schematic to create an empty workspace (this is actually the 'application' collection), then cd into that directory and immediately run the lib collection. I'd like to create my own schematic that calls both of these by chaining externalSchematic() but it seems like the lib collection assumes it will be passed a Tree whose root is one level deeper than the Tree created by the application collection.

In my collection I'm doing this:

  return chain([
    externalSchematic('@nrwl/schematics', 'application', options),
    externalSchematic('@nrwl/schematics', 'lib', libOptions)
  ]);

And that is producing the following error:

Error: Cannot find .angular-cli.json
        at readJsonInTree (/Users/matt/Projects/git/schematics/node_modules/@nrwl/schematics/src/utils/ast-utils.js:396:15)

I've logged the Tree after the application Rule has run on it, and the lib collection is expecting .angular-cli.json at the root of the Tree but it is at myapp/.

One possible solution is before I call the lib collection, I need to scope the tree to the myapp directory. A few articles I've read say that this is possible, but I have not been able to find any concrete examples.

It seems like the lib schematic assumes it will always be run from inside the directory of a workspace. If this is the case, to support creating a workspace and library inside it in one schematic, it would need an optional baseDir option.

Should all schematics support being able to be run within the rest of their package (or context, for lack of a better word) as well as being able to stand on their own and be used as building blocks for custom schematics?

[matt328]

#410 seems to address this issue.

[nweldev]

@matt328 great ! I read your issue yesterday, but I didn't know what to respond ... it's a good thing if I resolved it by chance 😀. You'll be kind to test to reproduce your issue using this PR branch, and to give feedback if you find any other bugs, because my focus here was only the Nx CLI, so I may not have solved every issues on app route with schematics composition.

[matt328]

@noelmace your PR branch seems like a good start, but because of focusing only on the CLI, I think there may be a few changes could be made to make this a more holistic solution. AFAICT you're grabbing the app-root from the command line and essentially setting it as a kind of global variable in app-root-path.ts, I think a better place for it might be in the options object.

I had a few other thoughts, but would like some input from the nx team on whether this is a feature they're interested in merging in or not.

[nweldev]

@matt328 As I said, this PR is just a quick and dirty workaround for the yarn link isssue, and I didn't want to address any other issue (given that a more global refactoring of the CLI is discussed at #369, and I didn't want to impact schematics). But feel free to comment it directly if you think of any enhancement.

[matt328]

@noelmace fair enough.

That all being said, I am still interested in the nrwl team's thoughts on a few schematics' options supporting an optional 'baseDir' instead of assuming it in order to support running schematics like app and lib from outside of the project dir.

[nweldev]

I'm not a member of "the nrwl team". @vsavkin ?

[vsavkin]

Every schematic takes two parameters: host: Tree, context: SchematicContext.

The lib schematic assumes that the host (the tree) starts at the root of the workspace. Default angular schematics make the same assumption.

You can achieve what you want by transforming the tree that the application schematic returns, so it matches what the lib schematic expects.

Should all schematics support being able to be run within the rest of their package (or context, for lack of a better word) as well as being able to stand on their own and be used as building blocks for custom schematics?

They are reusable already. Read here to find out more: ://blog.nrwl.io/announcing-nrwl-nx-1-0-33d888666bfc.

To make it more reusable, to satisfy your requirements, the lib schematic would have to receive some prefix to identify some subtree in the host tree, where it can execute. Since you can transform the tree itself, and the use case isn't very common, I don't think we should add the prefix.

Does it make sense?

[matt328]

Yes, absolutely. I agree transforming the tree seems like a much more idiomatic approach.

I am probably missing something trivial, but can you point me to an example, or which methods deal with transforming the tree to 'select' a subtree?

[vsavkin]

I don't believe the @angular-devkit/schematics package comes with a utility to select a substree, so you will have to build your own. The DelegateTree class is probably the closest thing to what you will have to build.

Closing this issue.

[FrozenPandaz]

@matt328 There is a filter rule which you can use to filter out unwanted parts of the Tree.

You can pass in a FilePredicate which contains a path of each file. If you check the beginning of the path, it should return a "subtree". I hope that solves your issue :)

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.