[Feature] Create boilerplate for library

[ritz078]

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]

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

[DxCx]

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]

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]

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

[jaumard]

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

[DxCx]

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]

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]

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

[vinaysoni]

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]

@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]

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]

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]

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.

[randyaa]

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]

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]

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]

@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]

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!

[rjcorwin]

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]

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]

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

[benetis-bentley]

@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]

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]

Check out https://github.com/gonzofish/angular-library-set

[achieverprince]

@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]

@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.

[rjcorwin]

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]

@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]

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]

@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]

@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]

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.

[hansl]

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]

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.

[filipesilva]

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.