New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Create boilerplate for library #1692

Closed
ritz078 opened this Issue Aug 14, 2016 · 73 comments

Comments

Projects
None yet
@ritz078
Contributor

ritz078 commented Aug 14, 2016

This is a feature request.

It will be great if we can create a basic boilerplate for creating libraries for pipes, components etc. This is the time when people may be willing to create components for angular 2 but due to the lack of this, it's tough. angular-cli already has a build system in place so it will be easier to integrate it here.

For example, If making a pipe, I won't need the whole src folder. A single file and a page where I can see the preview will do. This will make it easier for a lot of people.

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Aug 19, 2016

Member

We have this feature on the backlog, but it's probably only going to happen post v1 release.

Member

filipesilva commented Aug 19, 2016

We have this feature on the backlog, but it's probably only going to happen post v1 release.

@DxCx

This comment has been minimized.

Show comment
Hide comment
@DxCx

DxCx Aug 19, 2016

Hi,

I've found a Yeoman biolerplate that might be used until this one is resolved:
https://github.com/jvandemo/generator-angular2-library
(Haven't tested it yet, but will, soon..)

Hope it will help, and take down the pressure from ng2-cli team ;)

DxCx commented Aug 19, 2016

Hi,

I've found a Yeoman biolerplate that might be used until this one is resolved:
https://github.com/jvandemo/generator-angular2-library
(Haven't tested it yet, but will, soon..)

Hope it will help, and take down the pressure from ng2-cli team ;)

@jaumard

This comment has been minimized.

Show comment
Hide comment
@jaumard

jaumard Oct 1, 2016

Can't wait to use this in angular-cli :)
@DxCx did you test this generator finally ? Because doesn't seems up to date with last angular version :/

jaumard commented Oct 1, 2016

Can't wait to use this in angular-cli :)
@DxCx did you test this generator finally ? Because doesn't seems up to date with last angular version :/

@DxCx

This comment has been minimized.

Show comment
Hide comment
@DxCx

DxCx Oct 1, 2016

@jaumard I tested it long time ago,
yes i agree it's totally not up to date :\

DxCx commented Oct 1, 2016

@jaumard I tested it long time ago,
yes i agree it's totally not up to date :\

@jaumard

This comment has been minimized.

Show comment
Hide comment
@jaumard

jaumard Oct 1, 2016

Is there any resources about this for angular 2.0 ? I found for beta, alpha but nothing for the stable release...

jaumard commented Oct 1, 2016

Is there any resources about this for angular 2.0 ? I found for beta, alpha but nothing for the stable release...

@DxCx

This comment has been minimized.

Show comment
Hide comment
@DxCx

DxCx Oct 1, 2016

i think now that the final is out, they might want to implement this soon..
@Brocco is there any near plans about this feature?

DxCx commented Oct 1, 2016

i think now that the final is out, they might want to implement this soon..
@Brocco is there any near plans about this feature?

@tomwanzek

This comment has been minimized.

Show comment
Hide comment
@tomwanzek

tomwanzek Oct 1, 2016

Would love to see this feature rather sooner than later. I understand that the wonderful heroes 👍 behind the cli have to manage their scope, but I am crossing my finger that it does not take too long.

It is becoming somewhat of a bottleneck w.r.t. reusability of developed code. An ETA, even it broad strokes, would be most appreciated.

tomwanzek commented Oct 1, 2016

Would love to see this feature rather sooner than later. I understand that the wonderful heroes 👍 behind the cli have to manage their scope, but I am crossing my finger that it does not take too long.

It is becoming somewhat of a bottleneck w.r.t. reusability of developed code. An ETA, even it broad strokes, would be most appreciated.

@Brocco

This comment has been minimized.

Show comment
Hide comment
@Brocco

Brocco Oct 4, 2016

Contributor

@DxCx This is on the roadmap, but not in the immediate future.

Contributor

Brocco commented Oct 4, 2016

@DxCx This is on the roadmap, but not in the immediate future.

@vinaysoni

This comment has been minimized.

Show comment
Hide comment
@vinaysoni

vinaysoni Oct 21, 2016

It is sad to see that such an important feature is not being taken up as a priority. Angular2 is all about components but cli doesn't allow for making lib out of components, so that these can be reused across projects. Strange.

vinaysoni commented Oct 21, 2016

It is sad to see that such an important feature is not being taken up as a priority. Angular2 is all about components but cli doesn't allow for making lib out of components, so that these can be reused across projects. Strange.

@Brocco

This comment has been minimized.

Show comment
Hide comment
@Brocco

Brocco Oct 23, 2016

Contributor

@vinaysoni I understand that this may be higher on your priority list, but there are more pressing issues for the team to focus on, such as build and test performance. Rest assured that this is something that will be supported by the CLI.

Contributor

Brocco commented Oct 23, 2016

@vinaysoni I understand that this may be higher on your priority list, but there are more pressing issues for the team to focus on, such as build and test performance. Rest assured that this is something that will be supported by the CLI.

@vinaysoni

This comment has been minimized.

Show comment
Hide comment
@vinaysoni

vinaysoni Oct 23, 2016

Hi @Brocco

Thanks for your reassurance on this. However, let me explain my perception of the situation and why I thought that this feature (support for library development) is a vital part that should not have been missing in angular-cli .

Let me begin by saying that my comment was not motivated because of my immediate personal need for building libraries.

I tend to think of cli as a tool similar to Maven Archetypes. A tool which can provide me scaffold of different kinds/pieces of applications - so that one can get started quickly - without having to do plumbing and with the best blueprints/practices. angular-cli, along the same lines, generates project, modules, components, pipes, enums etc.

In the Java world, we have had Maven Archetypes, to generate different kind of projects (java command line app, a Jar file, a J2EE app, a web app, a Spring Camel App - and the list is virtually endless). But the most important part of Maven Archetypes - which is the closest parallel to angular-cli is generation of libraries.

We live in the world of libraries. Maven generated Java jar, war, ear, zip files to NPM packages. In an enterprise environment, everything is broken down into libraries. Now, when I think about - did anyone spend time in performance testing the Archetype for J2EE app or it's Unit tests, the answer is No. I feel that it is a minute piece in a much larger effort. If your blueprints are correct, and you are generating the code according to the blueprints, why do you need to do performance tests? angular-cli is not a full blown code generation tool. It generates only a starting point in code - with the right plumbing/blueprints/best practices.

On the other hand, what angular-cli should have had from the day one, was the ability to generate a Library. Even before "ng new project" came into place, there should have been "ng new lib datepicker"

This is because, there won't be a single Angular 2 project, worth the salt, within the enterprise, in real world, that would be composed of one single monolithic application. Only amatures, or Angular2 students, or a small time web developer would build such a monolithic application (without breaking it down into components). They may do it as a proof of concept, and therefore could be the use case for "ng new project" and the rest of what angular-cli has to offer today.

For corroboration, you may look at Angular2 itself. It acknowledges the assertion I am making by providing modules and components. The idea, the spirit and the very purpose of Modules was that when a module is created, it should be packaged in its own library. This is what we have done for years in the java eco system on the Swing based UIs for many years. But where is the support to do this in angular-cli?

Also, Modules were introduced late. Angular-cli should have been nimble to include "Support for Libraries" as soon as Modules surfaced. The current variance between angular-2 and angular-cli doesn't reflect nicely on angular-cli. Without support for libraries, I can't see enterprise applications adopting angular-cli.

"Support for Libraries" would be the most important Use Case for angular-cli within an enterprise software development environment. This may be a bit hard for traditional Java Script developer to grasp. But with a first class Object Oriented programming language (Typescript) it won't be JS developers but C# and Java developers who would be building the next generation of reusable components and apps using Angular2. GUI applications, with Typescript and Ng2 will be larger than the JS apps of the past and will have much greater element of reuse.

In contrast, generating a route, or a component, or Enum are nice to have features but are relatively simpler and pale in front of the need for "Support for Libraries".

Thanks
Vinay Soni

vinaysoni commented Oct 23, 2016

Hi @Brocco

Thanks for your reassurance on this. However, let me explain my perception of the situation and why I thought that this feature (support for library development) is a vital part that should not have been missing in angular-cli .

Let me begin by saying that my comment was not motivated because of my immediate personal need for building libraries.

I tend to think of cli as a tool similar to Maven Archetypes. A tool which can provide me scaffold of different kinds/pieces of applications - so that one can get started quickly - without having to do plumbing and with the best blueprints/practices. angular-cli, along the same lines, generates project, modules, components, pipes, enums etc.

In the Java world, we have had Maven Archetypes, to generate different kind of projects (java command line app, a Jar file, a J2EE app, a web app, a Spring Camel App - and the list is virtually endless). But the most important part of Maven Archetypes - which is the closest parallel to angular-cli is generation of libraries.

We live in the world of libraries. Maven generated Java jar, war, ear, zip files to NPM packages. In an enterprise environment, everything is broken down into libraries. Now, when I think about - did anyone spend time in performance testing the Archetype for J2EE app or it's Unit tests, the answer is No. I feel that it is a minute piece in a much larger effort. If your blueprints are correct, and you are generating the code according to the blueprints, why do you need to do performance tests? angular-cli is not a full blown code generation tool. It generates only a starting point in code - with the right plumbing/blueprints/best practices.

On the other hand, what angular-cli should have had from the day one, was the ability to generate a Library. Even before "ng new project" came into place, there should have been "ng new lib datepicker"

This is because, there won't be a single Angular 2 project, worth the salt, within the enterprise, in real world, that would be composed of one single monolithic application. Only amatures, or Angular2 students, or a small time web developer would build such a monolithic application (without breaking it down into components). They may do it as a proof of concept, and therefore could be the use case for "ng new project" and the rest of what angular-cli has to offer today.

For corroboration, you may look at Angular2 itself. It acknowledges the assertion I am making by providing modules and components. The idea, the spirit and the very purpose of Modules was that when a module is created, it should be packaged in its own library. This is what we have done for years in the java eco system on the Swing based UIs for many years. But where is the support to do this in angular-cli?

Also, Modules were introduced late. Angular-cli should have been nimble to include "Support for Libraries" as soon as Modules surfaced. The current variance between angular-2 and angular-cli doesn't reflect nicely on angular-cli. Without support for libraries, I can't see enterprise applications adopting angular-cli.

"Support for Libraries" would be the most important Use Case for angular-cli within an enterprise software development environment. This may be a bit hard for traditional Java Script developer to grasp. But with a first class Object Oriented programming language (Typescript) it won't be JS developers but C# and Java developers who would be building the next generation of reusable components and apps using Angular2. GUI applications, with Typescript and Ng2 will be larger than the JS apps of the past and will have much greater element of reuse.

In contrast, generating a route, or a component, or Enum are nice to have features but are relatively simpler and pale in front of the need for "Support for Libraries".

Thanks
Vinay Soni

@BernhardRode

This comment has been minimized.

Show comment
Hide comment
@BernhardRode

BernhardRode Oct 28, 2016

Hi,

i'm really appreciating the work on angular cli. i agree to what @vinaysoni wrote.

I want to get involved and make this feature come to life. Does somebody want to join and/or do a brainstorming session?

BernhardRode commented Oct 28, 2016

Hi,

i'm really appreciating the work on angular cli. i agree to what @vinaysoni wrote.

I want to get involved and make this feature come to life. Does somebody want to join and/or do a brainstorming session?

@piernik

This comment has been minimized.

Show comment
Hide comment
@piernik

piernik Nov 5, 2016

Here is temprorary workaround

I've managed to publish my project to npm.
Here's what I did.

In angular-cli project my module went to single folder (component-warpper).
In that folder I've added index.ts with list of modules and components to export.
I also added package.json file.
Then in command line go to this folder and npm publish.
Now I can import it as node_modules in other projects.

npm-publish

piernik commented Nov 5, 2016

Here is temprorary workaround

I've managed to publish my project to npm.
Here's what I did.

In angular-cli project my module went to single folder (component-warpper).
In that folder I've added index.ts with list of modules and components to export.
I also added package.json file.
Then in command line go to this folder and npm publish.
Now I can import it as node_modules in other projects.

npm-publish

@randyaa

This comment has been minimized.

Show comment
Hide comment
@randyaa

randyaa Nov 6, 2016

I wholeheartedly agree. We've been using Angular-CLI to manage a component library since alpha 0.0.34 but the webpack upgrade killed it.

The crawl phase of this kind of support really just needs:

  • to allow declarations to be emitted (maybe its possible now but with the first webpack release it threw all sorts of weird errors if you turned this on in tsconfig)
  • the ability to generate barrels that make the API surface obvious.
  • compile the barrels for distribution rather than build a single bundle.

We are still using Angular-CLI to build the demo app within our component library but have resorted to an NPM script like the following to build the library:

del-cli ./dist && tsc --outDir ./dist -p src/app && node-sass --include-path scss src/app -o ./dist && cp ./public/package.json ./dist && cp -R ./src/assets ./dist && cd src/app && find . -name '*.html' -exec cp --parents \\{\\} ../../dist \\; && cd ../.. && npm run inline-resources

which is clunky at best.

Material2 switching back to gulp should be a good indication that this support is needed.

randyaa commented Nov 6, 2016

I wholeheartedly agree. We've been using Angular-CLI to manage a component library since alpha 0.0.34 but the webpack upgrade killed it.

The crawl phase of this kind of support really just needs:

  • to allow declarations to be emitted (maybe its possible now but with the first webpack release it threw all sorts of weird errors if you turned this on in tsconfig)
  • the ability to generate barrels that make the API surface obvious.
  • compile the barrels for distribution rather than build a single bundle.

We are still using Angular-CLI to build the demo app within our component library but have resorted to an NPM script like the following to build the library:

del-cli ./dist && tsc --outDir ./dist -p src/app && node-sass --include-path scss src/app -o ./dist && cp ./public/package.json ./dist && cp -R ./src/assets ./dist && cd src/app && find . -name '*.html' -exec cp --parents \\{\\} ../../dist \\; && cd ../.. && npm run inline-resources

which is clunky at best.

Material2 switching back to gulp should be a good indication that this support is needed.

@piernik

This comment has been minimized.

Show comment
Hide comment
@piernik

piernik Nov 7, 2016

I hope this feature will be implemented very soon because my temprorary solution has issue with code completion in IDE (PhpStorm in my case).

piernik commented Nov 7, 2016

I hope this feature will be implemented very soon because my temprorary solution has issue with code completion in IDE (PhpStorm in my case).

@BenjaminBrandmeier

This comment has been minimized.

Show comment
Hide comment
@BenjaminBrandmeier

BenjaminBrandmeier Jan 5, 2017

Thanks for all the work so far, I'm a huge fan of angular-cli!

This issue is idle for about 2 months now. Any plan on when this will be implemented?
For the time being I will also try to come up with something on my own.

BenjaminBrandmeier commented Jan 5, 2017

Thanks for all the work so far, I'm a huge fan of angular-cli!

This issue is idle for about 2 months now. Any plan on when this will be implemented?
For the time being I will also try to come up with something on my own.

@dherges

This comment has been minimized.

Show comment
Hide comment
@dherges

dherges May 19, 2017

@filipesilva Ok, no deal.

Given that, I am looking for people from the community who are interested in implementing a packaging tool for Angular libraries. You can contact me here on my Twitter account

dherges commented May 19, 2017

@filipesilva Ok, no deal.

Given that, I am looking for people from the community who are interested in implementing a packaging tool for Angular libraries. You can contact me here on my Twitter account

@dherges

This comment has been minimized.

Show comment
Hide comment
@dherges

dherges May 19, 2017

In contradiction to what I just said a very very loooong time ago, I decided to publish ng-packagr.

Once again, I stress that I am not really able to support this tool for everyone. I believe that a community effort will lead to way better results than one individual can ever achieve. Feel free to use ng-packagr when it suits your needs! If you find any issues or want to add missing features, don't hesitate to contact me ... open issues or pull requests! It's always welcome!

dherges commented May 19, 2017

In contradiction to what I just said a very very loooong time ago, I decided to publish ng-packagr.

Once again, I stress that I am not really able to support this tool for everyone. I believe that a community effort will lead to way better results than one individual can ever achieve. Feel free to use ng-packagr when it suits your needs! If you find any issues or want to add missing features, don't hesitate to contact me ... open issues or pull requests! It's always welcome!

@rjsteinert

This comment has been minimized.

Show comment
Hide comment
@rjsteinert

rjsteinert May 25, 2017

It looks like our company is going to hold back on publishing our Angular modules to the Open Source community until this is figured out. We need to spend more time writing application code, less time maintaining our own custom build chain. We're happy to contribute some hours to helping standardize on this.

rjsteinert commented May 25, 2017

It looks like our company is going to hold back on publishing our Angular modules to the Open Source community until this is figured out. We need to spend more time writing application code, less time maintaining our own custom build chain. We're happy to contribute some hours to helping standardize on this.

@oliverjanik

This comment has been minimized.

Show comment
Hide comment
@oliverjanik

oliverjanik May 25, 2017

Thanks to everyone who threw starter packs together. We've struggled with this problem too and spent countless hours on our NG2 builds. In the end some combination of ngc, webpack and custom gulp tasks worked for us.

To angular team: Angular is loosing ground to React and Vue and others for developer mindshare. Mainly due to the fact that it's so damn hard to package reusable components. This should be your number 1 concern to kick start Angular community.

oliverjanik commented May 25, 2017

Thanks to everyone who threw starter packs together. We've struggled with this problem too and spent countless hours on our NG2 builds. In the end some combination of ngc, webpack and custom gulp tasks worked for us.

To angular team: Angular is loosing ground to React and Vue and others for developer mindshare. Mainly due to the fact that it's so damn hard to package reusable components. This should be your number 1 concern to kick start Angular community.

@achieverprince

This comment has been minimized.

Show comment
Hide comment
@achieverprince

achieverprince May 26, 2017

@oliverjanik
I absolutely agree with you.
Angular should support code sharing(library) as soon as possible

achieverprince commented May 26, 2017

@oliverjanik
I absolutely agree with you.
Angular should support code sharing(library) as soon as possible

@benetis-bentley

This comment has been minimized.

Show comment
Hide comment
@benetis-bentley

benetis-bentley May 26, 2017

@achieverprince that is disrespectful to framework authors. IMHO framework can be anything for anyone. And remember, we get it for free (which is kinda amazing) - if you don't like something - patches are always welcome

benetis-bentley commented May 26, 2017

@achieverprince that is disrespectful to framework authors. IMHO framework can be anything for anyone. And remember, we get it for free (which is kinda amazing) - if you don't like something - patches are always welcome

@orizens

This comment has been minimized.

Show comment
Hide comment
@orizens

orizens May 26, 2017

I used https://github.com/robisim74/angular-library-starter with 3 npm packages (http://npmjs.com/~orizens) thus far and it's working quite well with AOT

orizens commented May 26, 2017

I used https://github.com/robisim74/angular-library-starter with 3 npm packages (http://npmjs.com/~orizens) thus far and it's working quite well with AOT

@litzebauer

This comment has been minimized.

Show comment
Hide comment

litzebauer commented May 26, 2017

@achieverprince

This comment has been minimized.

Show comment
Hide comment
@achieverprince

achieverprince May 29, 2017

@benetis-bentley
Not at all, i am not disrespecting any framework or anyone.
We all are here because of the wonderful framework Angular and i love to use it.
I was just worried, Angular should not lose its popularity because of this.

My words would have been little harsh, i apologize if i have hurt any one. (edited my previous comment as well)

I do have to say, it is getting harder than angularjs because of the fragmentation... (angular 2, angular 4), even upgrading the framework from angular 4.0.3 > 4.1.2 broke the build (I think it has nothing to do with the framework, it is problem with the CLI)
It is going out of scope for this issue, so i ll leave it here.

I am just a encouraged developer looking to promote Angular.

achieverprince commented May 29, 2017

@benetis-bentley
Not at all, i am not disrespecting any framework or anyone.
We all are here because of the wonderful framework Angular and i love to use it.
I was just worried, Angular should not lose its popularity because of this.

My words would have been little harsh, i apologize if i have hurt any one. (edited my previous comment as well)

I do have to say, it is getting harder than angularjs because of the fragmentation... (angular 2, angular 4), even upgrading the framework from angular 4.0.3 > 4.1.2 broke the build (I think it has nothing to do with the framework, it is problem with the CLI)
It is going out of scope for this issue, so i ll leave it here.

I am just a encouraged developer looking to promote Angular.

@pjpenast

This comment has been minimized.

Show comment
Hide comment
@pjpenast

pjpenast May 30, 2017

@achieverprince

Unfortunately I agree with you. The Angular team has not been able to create a simple framework for the community. Instead he has put more inconveniences along the way than improvements.

In my team we have made a library for Angular 2/4 and we have had many problems to support the different versions and, above all, the AOT compilation.

If a framework wants to be successful it needs the community, and it is evident that Angular 2/4 has not been built with the community in mind.

It would be well if the Angular team would participate in the reflection created in this issue and tell us their impressions.

pjpenast commented May 30, 2017

@achieverprince

Unfortunately I agree with you. The Angular team has not been able to create a simple framework for the community. Instead he has put more inconveniences along the way than improvements.

In my team we have made a library for Angular 2/4 and we have had many problems to support the different versions and, above all, the AOT compilation.

If a framework wants to be successful it needs the community, and it is evident that Angular 2/4 has not been built with the community in mind.

It would be well if the Angular team would participate in the reflection created in this issue and tell us their impressions.

@rjsteinert

This comment has been minimized.

Show comment
Hide comment
@rjsteinert

rjsteinert May 30, 2017

Perhaps the idea of what an Angular Library needs to change to better go with the flow that Angular CLI supports. My thought is that instead of attempting to create an alternative set of build tools for Angular Libraries (ex. https://github.com/gonzofish/angular-library-set), libraries could be included directly into an Angular CLI based project in the /src/app/contrib/<angular library module name> directory so that the standard Angular CLI build chain picks it up. This might get messy with dependency management but Open Source projects like Drupal were able to foster a thriving ecosystem of community contributed modules that did not have the luxury of being able to use their own specific version of some dependency.

rjsteinert commented May 30, 2017

Perhaps the idea of what an Angular Library needs to change to better go with the flow that Angular CLI supports. My thought is that instead of attempting to create an alternative set of build tools for Angular Libraries (ex. https://github.com/gonzofish/angular-library-set), libraries could be included directly into an Angular CLI based project in the /src/app/contrib/<angular library module name> directory so that the standard Angular CLI build chain picks it up. This might get messy with dependency management but Open Source projects like Drupal were able to foster a thriving ecosystem of community contributed modules that did not have the luxury of being able to use their own specific version of some dependency.

@gonzofish

This comment has been minimized.

Show comment
Hide comment
@gonzofish

gonzofish May 30, 2017

@rjsteinert I agree that creating third-party tools don't solve the problem--I created Angular Librarian when I realized using the CLI wasn't going to be possible/too cumbersome to create a library.

I'd love to incorporate what librarian and other generators have done into the CLI to perpetuate a set of standards & practices when it comes to developing Angular code.

gonzofish commented May 30, 2017

@rjsteinert I agree that creating third-party tools don't solve the problem--I created Angular Librarian when I realized using the CLI wasn't going to be possible/too cumbersome to create a library.

I'd love to incorporate what librarian and other generators have done into the CLI to perpetuate a set of standards & practices when it comes to developing Angular code.

@DmitryEfimenko

This comment has been minimized.

Show comment
Hide comment
@DmitryEfimenko

DmitryEfimenko May 30, 2017

It's great to see so many people eager to help with this feature, however @filipesilva commented above:

I appreciate your offer but we're not yet open to contributions for this new feature :/

I think this means that Angular team is working hard on this feature. I only hope to see an update with the progress/roadmap to calm the community down a bit.

DmitryEfimenko commented May 30, 2017

It's great to see so many people eager to help with this feature, however @filipesilva commented above:

I appreciate your offer but we're not yet open to contributions for this new feature :/

I think this means that Angular team is working hard on this feature. I only hope to see an update with the progress/roadmap to calm the community down a bit.

@playground

This comment has been minimized.

Show comment
Hide comment
@playground

playground May 30, 2017

@DmitryEfimenko I think that would be great for the community to get an update with the progress as many of us in the community have been eagerly waiting for this feature to be out.

playground commented May 30, 2017

@DmitryEfimenko I think that would be great for the community to get an update with the progress as many of us in the community have been eagerly waiting for this feature to be out.

@achieverprince

This comment has been minimized.

Show comment
Hide comment
@achieverprince

achieverprince May 30, 2017

@DmitryEfimenko
I doubt that, cos the priority is still "required".
I think the Angular team has other major issues to deal with in their bucket.

I absolutely respect the team on prioritizing the issues (they know the actual situation)
I think we shouldn't pressure them as well, but what other choice do we got.

achieverprince commented May 30, 2017

@DmitryEfimenko
I doubt that, cos the priority is still "required".
I think the Angular team has other major issues to deal with in their bucket.

I absolutely respect the team on prioritizing the issues (they know the actual situation)
I think we shouldn't pressure them as well, but what other choice do we got.

@hansl

This comment has been minimized.

Show comment
Hide comment
@hansl

hansl May 30, 2017

Collaborator

Thanks everyone for your comments.

We really appreciate the discussion regarding libraries, but unfortunately this will not be implemented as part of CLI 1.x. There are multiple challenges that are insurmountable with library support and the current state of the CLI. Here are a few examples (in no particular order, and non-exhaustive):

  1. Webpack does not support the kind of modules we're looking for when publishing Angular libraries (e.g. metadata.json and d.ts files).
  2. Webpack does not support (but it's on the roadmap) outputting ES6 code like we suggest for flat modules.
  3. We do not have a story yet for a real multi-application projects, which is required for developing libraries (you want a demo app, a development app and an e2e app for developing libraries).
  4. We do not have support for custom templates, and creating templates right now is particularly expensive for us.
  5. We do not have support for having multiple entry points.
  6. There's no proper serve/test/e2e, or even build stories for libraries in particular. What I mean by this is that no design has been done yet on how e.g. ng serve in a library would even work. This is a surprisingly hard problem for us because the CLI should stay as simple-to-use as possible. Same goes for ng test; our current karma config relies heavily on Webpack (see points above).

There are of course other problems that arise when building a CLI tool that supports both libraries and applications while being simple and straightforward to understand.

As for the way forward, we are currently building our Angular Development Kit and in the early design stages. We are rethinking the build story entirely and taking into account libraries from the start. Unfortunately the timeline for the DevKit is rather fuzzy, but once we have something more concrete we will share it with the community.

I'm going to lock this conversation for now, to make sure people coming into this thread see this message. I am not entirely sure this issue will live on as we move to the DevKit, but wherever news happen on library support in the CLI I will point to from this thread so people can follow.

Thanks everyone.

Collaborator

hansl commented May 30, 2017

Thanks everyone for your comments.

We really appreciate the discussion regarding libraries, but unfortunately this will not be implemented as part of CLI 1.x. There are multiple challenges that are insurmountable with library support and the current state of the CLI. Here are a few examples (in no particular order, and non-exhaustive):

  1. Webpack does not support the kind of modules we're looking for when publishing Angular libraries (e.g. metadata.json and d.ts files).
  2. Webpack does not support (but it's on the roadmap) outputting ES6 code like we suggest for flat modules.
  3. We do not have a story yet for a real multi-application projects, which is required for developing libraries (you want a demo app, a development app and an e2e app for developing libraries).
  4. We do not have support for custom templates, and creating templates right now is particularly expensive for us.
  5. We do not have support for having multiple entry points.
  6. There's no proper serve/test/e2e, or even build stories for libraries in particular. What I mean by this is that no design has been done yet on how e.g. ng serve in a library would even work. This is a surprisingly hard problem for us because the CLI should stay as simple-to-use as possible. Same goes for ng test; our current karma config relies heavily on Webpack (see points above).

There are of course other problems that arise when building a CLI tool that supports both libraries and applications while being simple and straightforward to understand.

As for the way forward, we are currently building our Angular Development Kit and in the early design stages. We are rethinking the build story entirely and taking into account libraries from the start. Unfortunately the timeline for the DevKit is rather fuzzy, but once we have something more concrete we will share it with the community.

I'm going to lock this conversation for now, to make sure people coming into this thread see this message. I am not entirely sure this issue will live on as we move to the DevKit, but wherever news happen on library support in the CLI I will point to from this thread so people can follow.

Thanks everyone.

@angular angular locked and limited conversation to collaborators May 30, 2017

@hansl

This comment has been minimized.

Show comment
Hide comment
@hansl

hansl May 30, 2017

Collaborator

Addendum: We are in the process of adding custom template support to the CLI, and with it another tool that can be used to generate just templates but outside the CLI. We will consider having a scaffold for basic library projects, but it will not be part of the Angular CLI.

Collaborator

hansl commented May 30, 2017

Addendum: We are in the process of adding custom template support to the CLI, and with it another tool that can be used to generate just templates but outside the CLI. We will consider having a scaffold for basic library projects, but it will not be part of the Angular CLI.

@hansl

This comment has been minimized.

Show comment
Hide comment
@hansl

hansl May 30, 2017

Collaborator

I created #6510 to keep this thread locked, but the conversation going. Please continue the discussion over to the new issue, so that people coming here see the official answer.

Collaborator

hansl commented May 30, 2017

I created #6510 to keep this thread locked, but the conversation going. Please continue the discussion over to the new issue, so that people coming here see the official answer.

@hansl hansl removed their assignment Feb 6, 2018

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva May 2, 2018

Member

In version 6.0.0 of Angular CLI you will be able to create, test and lint libraries.

This functionality is available in the latest RCs of 6.0.0, and documentation can temporarily be found at https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/create-library.md. Once 6.0.0 reaches final, the documentation will be moved to the main wiki.

Member

filipesilva commented May 2, 2018

In version 6.0.0 of Angular CLI you will be able to create, test and lint libraries.

This functionality is available in the latest RCs of 6.0.0, and documentation can temporarily be found at https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/create-library.md. Once 6.0.0 reaches final, the documentation will be moved to the main wiki.

@filipesilva filipesilva closed this May 2, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.