Repository navigation
[Feature] Create boilerplate for library #1692
Description
Activity
We have this feature on the backlog, but it's probably only going to happen post v1 release.
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 ;)
Is there any resources about this for angular 2.0 ? I found for beta, alpha but nothing for the stable release...
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.
Reacted by vinaysoni, Robert Kiemele, Bradley Baysinger, mscelina, Francois D'Agostini, Marco Pragliola, Denys Vuika and jamiewastinIt 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 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.
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 SoniReacted by Dave Benjamin, raviganesh12, Oliver Janik, Robert Kiemele, Darrel O'Pry, Scott, Stefan Staynov, Dmitry A. Efimenko, Aliaksandr Zhukau, Jonathan Gelin and 18 moreReacted by Bernhard Rode, Randy Aldrich, mark1010, valdestron, Shijir Tsogoo, Jaron Thatcher, Jan Zieliński, Christian Ulmann, Tony Franzese, eviljoe and 18 moreHi,
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?
Reacted by Dmitry A. Efimenko52 remaining items
- Reacted by Matt Fehskens
@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.
Reacted by Piernik, pjpenast and Marco MontanariUnfortunately 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.
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 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.
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 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.
Reacted by Matt Fehskens and Jeba Prince@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.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):
- Webpack does not support the kind of modules we're looking for when publishing Angular libraries (e.g. metadata.json and d.ts files).
- Webpack does not support (but it's on the roadmap) outputting ES6 code like we suggest for flat modules.
- 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).
- We do not have support for custom templates, and creating templates right now is particularly expensive for us.
- We do not have support for having multiple entry points.
- 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 servein 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 forng 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.
- locked and limited conversation to collaborators
on 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.
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.
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
srcfolder. A single file and a page where I can see the preview will do. This will make it easier for a lot of people.