Add module generator

[tobi-or-not-tobi]

Great work on this! Very convenient to build a library. I'd love to see if we can have:

• a module generator
• additional path where the module/component/etc are being added

[gonzofish]

First off, thank you! Both for the compliment and for using the library.

This is an interesting request. I get wanting a secondary module--the challenge I see is that we'd need a convenient way of providing the right destination for files. Currently it's more or less hard-coded that all components drop into src/{{ component selector }}, services to src/services, etc.

Perhaps we can make it so that if the user names prefixes the component/directive/service name with {{ module name }}/ we can place it? I don't know, this will require some experimentation.

[tobi-or-not-tobi]

I'm used to angular-cli where I'd start with building a module:

ng g m my/path/modname

followed by adding components/services/etc with

ng g c my/path/first-comp
ng g s my/path/first-services

This would result in a reusable module. Personally I'm not a big fan of shared services directory, I tend to have a more context driven approach. That being said, it makes more sense in a library as the number of modules/components/services is typically smaller.

If you'd translate the above concept to this CLI, it could work very similar:

ngl m my/path/modname
ngl c my/path/first-comp

[gonzofish]

That all makes sense, especially given that I'm trying to keep the API close to the CLI's...I'm not sure what an ETA on something like this would be, since it may have some further reaching impacts.

Again, thanks for a good suggestion!

[gonzofish]

Does it bother you that, in the Angular CLI world, the module folders live alongside the app module's components & services? That seems really messy. I'm trying to figure out a good way to organize everything.

Might be to put components into a components directory and then any modules into a modules directory? Althought I hate adding another level...

[tobi-or-not-tobi]

Sorry for a late reply here @gonzofish. I haven't been here for a while. I'm not sure if I got your question right, but I'll give it a try.

I'm used to create projects using the angular CLI. While I'm building an app, i'm organizing components into several modules. A module might have multiple components and services, but soon enough I try to make things reusable and they are moved into their own module. So far, my project work is mainly organized in a single app. The only reason for this is, is that I haven't seen an approach that makes it easy to:

• separate out a module inside a library
• add that library to the project
• co-develop the library and the app without having to commit/install continuously.

Ideally, the library would be created with angular cli, as this is the comfort zone.

Back to the question (hopefully): short answer: No. I actually don't like a components directory or a services directory. It doesn't help during development. I like to split things up by context, i.e. a directory that contains module with multiple components and services that are build together. This makes it also easy to move them out at one point in time. You can simply move out the directory including all dependencies.

[gonzofish]

Hmm, interesting comments. So in your preferences, where would the initial module live? Would it be something like ./src/my-module/? A recent addition for scoped packages may help facilitate this...

We could add an option to project initialization ngl init --module=my-module which would add that my-module folder? So the structure would load up like this:

|__examples/
   |__example.component.html
   |__example.component.ts
   |__example.main.ts
   |__example.module.ts
   |__index.html
|__node_modules/
   |__...
|__src/
   |__my-module/
       |_my-module.module.ts
   |__<library name>.module.ts
   |__index.ts
   |__test.ts
|__webpack/
   |__webpack.dev.js
   |__webpack.test.js
|__.gitignore
|__.npmignore
|__index.ts
|__karma.conf.js
|__package.json
|__README.md
|__tsconfig.json
|__tslint.json

This would actually assist in moving a step closer towards monorepo capabilities, too.