Proposal: Auto add (providers, directives, pipes, styles, styleUrls) when adding 3rd party libs, etc.

[NathanWalker]

Discussion on AngularAir today regarding 3rd party libraries (https://plus.google.com/events/c7m79d5o04nom5eednk5ecqtebk) brought up an interesting thought.
See also: angular/angular#5503

If 3rd party libs all adhered to a certain naming convention and style when exporting necessary services, directives, pipes, etc., it would be incredibly helpful if this CLI could auto-annotate the src code files with the necessary directives, providers, pipes, etc.

Consider the following scenario:

1. User wants to use ng2-image-lazy-load (https://github.com/NathanWalker/ng2-image-lazy-load)
2. Since it followed certain conventions, IMAGELAZYLOAD_PROVIDERS, the CLI might provide an additional helpful aid (command can be whatever, just using add-lib for example):

ng add-lib ng2-image-lazy-load 

It would proceed to run npm install ng2-image-lazy-load, then prompt with a couple questions:

$ Would you like this provider as part of the bootstrap? (y/n)

If "y":

$ Please provide the path to the src file which bootstraps your app:
$ src/bootstrap.ts

It would add the import statements and append the aptly named [lib_prefix]_PROVIDERS in the user's app bootstrap.
If the lib contained no constants with PROVIDERS in the name, it would modify nothing.

If "n":

$ Please provide the path of the component you would like the providers added to:
$ src/components/main.component.ts

It would add the import statements and append the libraries aptly named PROVIDERS in the viewProviders of the component.

Similar scenarios would apply for DIRECTIVES, PIPES, etc.

If this were possible, every 3rd party lib could suggest using the CLI as the first option to install, followed by manual npm install.

/cc @jvandemo, @gdi2290, @valorkin, @ocombe, @jeffwhelpley, @PascalPrecht, @mgechev, @ludohenin, @robwormald

[IgorMinar]

the proposal sounds reasonable to me (with some tweaks). I think that we should prefer local import over global import, so I'd reorder the options.

Would you like to create a test package(s) in npm that we can experiment with?

[NathanWalker]

adjective: adlib; adverb: adlib
_musical context_:

Jazz musicians may adlib during a performance, meaning they are free to vary tempo and instrumentation.

_programmers context_:

When using any framework to create an application, there will come a time when a developer must adlib to complete the applications specifications.

Might be a fun command: adlib

[robwormald]

i think perhaps a simple solution for this would be something along the lines of

//myPluginRoot.ts
import {MyPluginServiceA, MyPluginServiceB} from './services';
import {MyDirectiveA, MyDirectiveB} from './directives';
import {MyPipeA, MyPipeB} from './pipes';

//export the named stuff for granular usage
export * from './services'
export * from './directives'
export * from './pipes'

//use es6 default syntax to export the "plugin"
export default {
  providers: [MyPluginServiceA, MyPluginServiceB],
  directives: [MyDirectiveA, MyDirectiveB],
  pipes: [MyPipeA, MyPipeB]
}

users and tooling are then easily able to do :

//naming is irrelevant here
import myPlugin from 'myPlugin'

//now its consistent:
myPlugin.directives
myPlugin.services
myPlugin.pipes

and this is easily done with templating, as the actual name of the export is "default" - no weird lookups necessary and no NAMING_CONVENTIONS to force / invent.

see http://plnkr.co/edit/Yi1e3ifiX0gSqd8Qs2h4?p=preview - i added a little plugin registration helper too, which @IgorMinar will probably yell at me about.

[NathanWalker]

That's the best solution I've heard yet @robwormald. Very clean and simple.

I could pull your plunk (the gist of it anyway) into a repo tomorrow or
Friday and publish it so it could be experimented with in this setup.

[ludohenin]

@robwormald I like it very much

[ocombe]

+1 on this solution @robwormald :)

[jvandemo]

@robwormald — Brilliant, love your proposal! 👍

[robwormald]

Go for it! (maybe not the helper thing...)

On Dec 10, 2015, at 12:16 AM, Nathan Walker notifications@github.com wrote:

That's the best solution I've heard yet Rob. Very clean and simple.

I could pull your plunk (the gist of it anyway) into a repo tomorrow or
Friday and publish it so it could be experimented with in this setup.

On Thu, Dec 10, 2015 at 12:03 AM Rob Wormald notifications@github.com
wrote:

i think perhaps a simple solution for this would be something along the
lines of

//myPluginRoot.tsimport {MyPluginServiceA, MyPluginServiceB} from './services';import {MyDirectiveA, MyDirectiveB} from './directives';import {MyPipeA, MyPipeB} from './pipes';
//export the named stuff for granular usageexport * from './services'export * from './directives'export * from './pipes'
//use es6 default syntax to export the "plugin"export default {
providers: [MyPluginServiceA, MyPluginServiceB],
directives: [MyDirectiveA, MyDirectiveB],
pipes: [MyPipeA, MyPipeB]
}

users and tooling are then easily able to do :

//naming is irrelevant hereimport myPlugin from 'myPlugin'
//now its consistent:
myPlugin.directives
myPlugin.services
myPlugin.pipes

and this is easily done with templating, as the actual name of the export
is "default" - no weird lookups necessary and no NAMING_CONVENTIONS to
force / invent.

see http://plnkr.co/edit/Yi1e3ifiX0gSqd8Qs2h4?p=preview - i added a
little plugin registration helper too, which @IgorMinar
https://github.com/IgorMinar will probably yell at me about.

—
Reply to this email directly or view it on GitHub
#96 (comment).

—
Reply to this email directly or view it on GitHub #96 (comment).

[valorkin]

Will not this push to use MVC like folder separation?
Like for angular 1 really was really popular controllers\directives\templates separation
which became really fast unusable in large apps
that all moved to components separation all related to component in one folder
a bit later nested components and common folders appeared as a practice

+1 to @robwormald that we should not push/invent name conventions

PS: I am never using generators, and not allow to, guys should understand what and why they are doing :)

[robwormald]

this is for third party packages (like yours) which will presumably ship via NPM, and thus the structure of the package is mostly irrelevant to the user. The structure internal to the module / plugin is entirely up to you, that was just a quick and dirty demo.

[jvandemo]

@valorkin — I think using a folder structure with directives, services and pipes makes sense for libraries (the Angular team also does this internally in the Angular source code) although the library author could decide to use another structure.

The structure for an actual application (not a library) would be component driven though, if that makes sense.

[valorkin]

just said my IMHO
Angular team actually uses components structure (but call it modules) and MVC separation inside of it
https://github.com/angular/angular/tree/master/modules/angular2/src

[jvandemo]

@valorkin — I think the Angular repository (in its current form) is hard to compare to a third party library.

However, if we peek inside one of the modules, then we can see a similar structure e.g.: https://github.com/angular/angular/tree/master/modules/angular2/src/common

I think such a structure is probably closer to what most (smaller) libraries will contain.

If you have a larger library that contains modules then it definitely makes sense to create a module folder structure. Ultimately the library author should decide.

Although one could argue that it would be better to split into different repositories than in different modules.

Would be great if there is an Angular 2 ecosystem with a lot of very small libraries (as in node).

What are your thoughts on splitting into different repositories? Thanks!

[valorkin]

Taking in account user option to to require and bundle only require part of libs
it is awesome opportunity to minimize js size and bootstrap time
(as a consequence of reduced amount of js to be parsed by VM)

modules are optional
splitting in components like this: https://github.com/angular/angular/tree/master/modules/angular2/src
seems to me as proven concept, IMHO