search

angular / angular-cli

CLI tool for Angular
https://cli.angular.io
MIT License
26.76k stars 11.97k forks source link

[RFC] Library Support and Boilerplate Comment Thread #6510

Closed hansl closed 6 years ago

hansl commented 7 years ago

As a follow up for https://github.com/angular/angular-cli/issues/1692#issuecomment-304970595.

Continue the conversion here.

achieverprince commented 7 years ago

@hansl

Thanks for the official reply. Hoping to see a update from the team soon :)

robwormald commented 7 years ago

Thoughts from me (I maintain ngrx as well as Angular devrel)

So long term, this will land in the devkit, but that's a fairly major architecture change. In the interim, lets start with a "seed" style repo people can just fork and start work with.

MVP should basically:

Anything beyond that is going to quickly get into the realm of bikeshedding best practices / fav code coverage tool of the week, so let's start minimally and go from there.

mattem commented 7 years ago

First off thanks @hansl for the update, it's very much appreciated.

I'd like to understand the future of ng cli, where this fits with the Angular Development Kit and the tools to generate custom templates.

Our company has put a lot of time and effort in to getting on board with Angular 4.x and using the ng cli, we have been though many refactors thought the libraries lifecycle. We are currently using a custom build process simular to what @robwormald describes for building and testing our component libraries, which we were hoping could be removed once this feature landed in cli.

I'm left worrying that we will have to change our non-library applications build process again once these new tools land, or will they just for library projects?

robwormald commented 7 years ago

At Google, we use the terms "binary" and "library" for this:

The current Angular CLI was, from the very beginning, built to be a tool for managing binaries. In the early days, when we used ember-cli + broccoli, outputting libraries would have been simpler to do, as it was less opinionated and more flexible. The Angular community demanded (rightly, IMO) that we switch over to Webpack. Webpack is designed to build binaries, and so we're kind of stuck.

@mattem the whole point of not giving you access to the internals of Webpack is that its our goal to allow seamless transition as we evolve the underlying tools. Long term our goal is to dramatically simplify the whole process, but that takes time. The point of this thread is to provide an interim solution.

robwormald commented 7 years ago

@mattem long term, we're working on eliminating the need to ship metadata and such to npm in favor of shipping precompiled code. We have this setup in place to allow us to be flexible with the compiler APIs (this is what allowed us to change everything in between v2 - v4) - once we're happy with the API we'll mark it as public, which opens up a number of really cool new possibilities. This is (currently) on the roadmap for about a year out, but the work to prepare for that is in progress.

hansl commented 7 years ago

@mattem Rob didn't answer this question, so I'll take a stab:

I'd like to understand the future of ng cli, where this fits with the Angular Development Kit and the tools to generate custom templates.

The DevKit will be a set of libraries and tooling that you can script or develop against. Parts of it will be to build, test and generate files. This sounds really generic because it is; it will be a lot of conventions enforced at the API level so that tools (such as IDEs, scripts or CIs) will work in a similar way.

The CLI in the future (version 2? 3?) will only be a tool that uses the DevKit in the background, abstracting it from users. If you use the CLI today, you should be very familiar to the CLI in the future. The real difference is that every pieces underneath will be able to be used independently by other tools. So you could see, e.g., a VSCode extension that knows how to build your app/library, which uses the same code path as the CLI.

oliverjanik commented 7 years ago

Pardon my French, but WTF? Has Angular jumped the shark?

One of the top priorities of Component framework is to facilitate re-usability of components. I don't know what Angular Devkit is and I don't understand what multi-application support means. I just want to package a measly combo-box and share it with the team and/or the world.

Lack of standardization and lack of guidance in this area is really hurting the ecosystem.

I realize that the underlying complexity is beyond understanding of any casual app developer who just uses NG but, frankly, put your hand on your heart and ask yourself this question:

"Have we dug ourselves into a complexity black hole?"

The promise of NG2 was to banish the complexity and unfamiliarity of NG1. Time for a sincere introspection is now.

Meanwhile for us, who have to explain to our managers what JIT is or AOT and why builds randomly break even though they're perfectly good Typescript and why it takes so long to extract common functionality that already works to be used in another project, well, we might be forced to jump the ship.

yordis commented 7 years ago

My 2 cents in the whole topic from the previous thread to the one I started.

First @oliverjanik I couldn't say it better.

I took the decision of do not move out of my Front end stack again, I can't be jumping between stacks while I want to create something mature that allow me to focus on the business rather than being "cool" or just change it for a minor improvement at the end of the day.

So I went back to Angular (I was in Angular 1 long time ago) because I saw the architecture changes and it looks fantastic pretty much, but then I hit wall that shouldn't be there for me #6466 , After a full week trying to get answer to my concern I realice that I will have to hack the setup and it will no be straight forward either.

Why should I hack something some simple as @oliverjanik explain, when all I want to do is to create the most common use case on any ecosystem: shared a reusable module.

CLI are meant to be use base on the ecosystem, I got that, but the same time there is common use case that should be fixed already, specially when there is a lot of people with the same concern.

And then even worse you read something like this https://github.com/angular/angular-cli/issues/1692#issuecomment-302742332 that scare me a lot as something that wants to think in long term and base out a whole company on it.

If you (Angular Ecosystem main contributors) don't want to support your community (it doesn't mean you didn't do it at all), just be clear with us. A lot of people depends of you and sometimes it doesn't even take a week for implement something with a huge impact for the good of the community. No everything can be Google interests but at least be clear about it.

I am speaking from the side of a person that just started 2 weeks ago, a person that was happy in React ecosystem but always wanted to go back to Angular for many reasons, a person that wants to be part of your community and probably in the future could be a potential contributor, making your life easier.

Please think in your community, it will pay off in the long term and don't read this and feel bad about it and think in the negative mindset because I can't express how thankful I am that you did an amazing job on Angular but at the same time, don't let small things like this one opaque your greater.

rjcorwin commented 7 years ago

just be clear with us

@yordis Agreed. Before we talk about technical solutions, there should be a mention of this issue in the Docs. I created a PR https://github.com/angular/angular/pull/17129

My 2 cents is that for most people, they just need to know there is some direction in creating reusable Angular Modules. If we could add @robwormald's solution to the docs, then count me in. It doesn't need to be the most technically optimal solution for now, there is a lot of value in rallying behind non-optimal solutions for the sake of having consensus. Until then, Angular is the framework that "Makes great decisions so you don't have to... but you can't reuse your code."

robwormald commented 7 years ago

@oliverjanik @yordis @rjsteinert appreciate the feedback.

I just want to package a measly combo-box and share it with the team and/or the world.

I don't want to in any way minimize what you're saying here, because there's a lot of good points in it - but we should be clear that this is absolutely possible today. Its absolutely more complicated than it needs to be, but there are some good examples out there you can use as a reference.

A great one to look it is ng-bootstrap: https://github.com/ng-bootstrap/ng-bootstrap/

Here's the packaging format guidelines Jason presented at ng-conf: https://goo.gl/AMOU5G - admittedly I had to ask around to track that down, so we'll see about getting that posted somewhere more reachable.

@filipesilva has also done great work on writing up a guide for this in the docs, and a starter repo you can clone, and unfortunately the pull request got caught behind our infrastructure changeover. I'm working on getting this merged ASAP.

You can see that PR here: https://github.com/angular/angular/pull/16486 And the starter repo here: https://github.com/filipesilva/angular-quickstart-lib

Lack of standardization and lack of guidance in this area is really hurting the ecosystem.

It should be said that there's pretty much zero precedent for what we're trying to do here. Some of the challenges in this space alone:

...and all this is before we even start talking about Angular! Again, we're totally with you on this, but this is an ecosystem we're all a little bit at the mercy of. One thing that became quite clear when joining the Angular team is that we really are working at the bleeding edge - a lot of this stuff we literally have to invent as we go. It's a big reason I love my job, but it means that sometimes, yeah, you're gonna have to try things that sometimes won't work.

Example: the FESM format mentioned in the above doc works great for projects like ngrx, but unfortunately it had an impact on libraries like Angular Material, and so we're tweaking those guidelines for cases like that. A lot of these things you just don't know until you try.

One thing I think is important to understand here is that we (the Angular team) are dealing with this problem twice - once internally, for all the projects at Google and Alphabet that use Angular, and once for the FOSS community. Why?

At Google, we use an entirely different set of tools than are used in the open source world:

This means @hansl, who runs the open-source facing CLI project, is doing work that can't be shared by the internal Angular infrastructure teams (because we're not using Webpack et al), and vice-versa.

If we're being perfectly honest, this situation, and the internals of CLI as it exists today are not sustainable. Having a great scaffold from the ember-CLI project and leveraging @TheLarkInn and the awesome Webpack community allowed us to get a functional tool that was usable ASAP - but its led to a fairly significant amount of technical debt.

This isn't unexpected, and again, it's the reason we've held fast on not exposing the Webpack internals - we knew at some point, we'd have to pay off that technical debt, and we want to do so without exposing developers to churn.

The idea of the DevKit project is to finally allow us to share tooling between our internal and external customers - meaning @hansl and co aren't duplicating work, and excitingly, developers of teams at Google can help improve the same tooling open-source Angular developers use. @alexeagle has written a bit about this - https://medium.com/@Jakeherringbone/what-angular-is-doing-with-bazel-and-closure-21f526f64a34 - We've requested and helped design features from the Typescript team (like the transformers pipeline) that will finally unlock further code sharing and streamline our TS tooling.

If you don't care about how it works, then you won't have to care about how it works. It will, however, allow developers who want to, to build and extend the toolchain to do all sorts of powerful things. As an off the cuff example - we speak to lots of teams who want a standard boilerplate for their internal packages. DevKit will enable that - and not in a patched-on-the-side fashion, but baked into the design from the beginning. Want to plug into the generation pipeline and add your own custom license to every generated file? Sure.

All software is about balancing tradeoffs - we made a decision early on to provide open-source developers who want to be productive building applications a tool they could use immediately. I think, with a few exceptions, we've delivered on that goal. We're trying to do this while also balancing long-term maintainability, and delivering for the teams at Google that pay our salaries (and those of our awesome contractors) and make the entire Angular project possible at all, and there's only so many hours in the day!

If there's anything else you'd like clarification on here, please don't hesitate to ask.

pjpenast commented 7 years ago

@robwormald I do not understand why you say the problem is Webpack when there are thousands of examples of libraries built with Webpack

I completely agree with @oliverjanik, it is not understandable that from the team of Angular is not given priority to this. You can't make a framework based on compononents that doesn'tallow reuse of components. It's completely absurd.

In our development team, the first thing we did when we started working with Angular was to create a library of reusable components for all our modules. It does not make sense that Google has not thought the same way.

We have also been able to create reusable components such as a combo box without effort. If you are interested in knowing our project is this:

https://github.com/Stratio/egeo

yordis commented 7 years ago

Two main concern in how to approach this because I am misunderstanding.

  1. https://github.com/angular/angular-cli/issues/6466 Based on that issue, why do the CLI force me to have a bootstrap application when I only want to have NgModule and use the CLI for run the testing in this case. I do not understand why is that a big deal right now, when it's pretty much run the karma testing but for some reason something is stopping before complaining about some code analysis I guess, no clue why. The use case is pretty straight forward. 3 applications. First application for the reusable core features. Second application for the github page release. Third application for development testing, like chicken sink for visual testing pretty much, exactly what material2 would use without needs of any gulp or any other setup.

What do we need to do for tackle that use case without any special case? Because so far there is only one issue with it

  1. What happen if we just push the Angular projects as Typescript projects rather than Javascript? You mentioned that Webpack do not compile from node_modules?! The last time I check you actually have to put the exclude filter for node_modules for stop that to happening. Right?!
dherges commented 7 years ago

Please keep it simple.

Now we have that Angular Package Format, we need a projection: (entryFile: string = 'src/public_api.ts') => NgPackageFormat

interface NgPackageFormat {
  main: string,
  module: string,
  /* ... */
}

It will take more than just one input property ... we need ONE workflow for creating that Angular Package Format from source. I agree with @robwormald that unit testing support is a major part. Taking away the burden of configuring several build steps manually will be the NEXT step towards. I do not care about the second and third steps for now. You will fail and the ng cli has failed for almost a year in doing the big "Library developer mode". Please take one decision. Do one step.

-- edit: I excuse for the bold wording. Please let us just stay focused on improving step by step.

robwormald commented 7 years ago

@pjpenast please read the package format doc, as it dives into a lot of this, but i'll excerpt the important bit:

In today’s JavaScript landscape, developers will consume packages in many different ways. For example, some may use SystemJS, others could use Webpack. Still, others might consume packages in Node or maybe in the browser as a UMD bundle or through global variable access.

The Angular distribution package supports all of the commonly use development tools and workflow, and adds emphasis on optimizations that result either in smaller application payload size or faster development iteration cycle (build time).

While everyone in this thread is likely using angular CLI, there's a significant portion of our userbase who aren't, or can't, for various reasons. If we're going to have an officially supported tool, it can't exclude anybody who's not using webpack.

You can't make a framework based on compononents that doesn'tallow reuse of components. It's completely absurd. It does not make sense that Google has not thought the same way.

@angular/material is used by dozens of teams inside of google, and they share their own components amongst themselves - but again, none of them are using webpack or any of the tooling you use - they all use closure compiler, which won't accept webpack output! We compile everything from source - it's simply a different environment.

In our development team, the first thing we did when we started working with Angular was to create a library of reusable components for all our modules.

Great! Maybe you could blog about your solution, and share what you've learned with the Angular community, or write up your findings and share them with us?

robwormald commented 7 years ago

@dherges please refer to the Code of Conduct before posting further. Feedback is welcome, but keep it civil.

Now we have that Angular Package Format, we need a projection: (entryFile: string = 'src/public_api.ts') => NgPackageFormat

At a high level, this is exactly what the DevKit is about. It's not something we can simply tack onto the existing CLI. In the interim, a seed/starter project as linked above that implements these patterns seems like a reasonable first step. See https://github.com/filipesilva/angular-quickstart-lib.

pjpenast commented 7 years ago

@robwormald I understand that there are many different frameworks and you have to try to adapt them all (SystemJS, Webpack, Rollup, etc.), even in Google you have a framework different from the community as explained, which is a problem from my point of sight.

But that problem exists for all the libraries and frameworks of Javascript, it doesn't have to be an inconvenience that will stop you from approaching the community and make it easier for people to develop in Angular.

@angular/material is used by dozens of teams inside of google, and they share their own components amongst themselves.

Yes Angular Material is a good example of reusable code in Angular and we have used it as a reference for our library. But it is a rather complex solution and isn't easy to implement.

The problem in the ecosystem of Angular isn't that it is not possible to make reusable code libraries, we have done it, the problem is that it isn't easy to implement.

Great! Maybe you could blog about your solution, and share what you've learned with the Angular community, or write up your findings and share them with us?

In my team we would be happy to share our knowledge with the community of how we have built a library of components in Angular. Can you tell me the way you have to share this knowledge?

Thanks!

ppenalver commented 7 years ago

I think it's a big mistake to not listen to the community, in my opinion if you could ask everybody the majority would agree that an official way of making a reusable components' library is necessary. At least the Angular team and the angular material team could put together a simple guide in documentation of how angular material achieves this.

I work with @pjpenast and as he posted, we made work our library with AoT in other projects after a lot of effort and work. The solution was to see how (https://github.com/angular/material2) does this trying to understand its code.

They use the angular wrapper of typescript compiler to create d.ts and metadata.json, Rollup to create bundles and also they replace references to html and styles files with the content of files inline in metadata and javascript generated files.

We assume that Angular is backed by an important company like Google, we assume that Angular has a great support service and community, Above all we assume that if Angular aspires to be the best framework for doing reusable components,there should be no excuses for not having an official method of developing a library after a stable year of life of the framework.

deebloo commented 7 years ago

The one immediately actionable item in this thread seems to be the documentation and link to a library seed project. I think it is fair to say that creating libraries isn't as straight forward as one would like but it is certainly possible. We should try to keep things constructive and less hyperbolic.

@hansl would it be possible to build a tool and works WITH a cli generated project to create a library? (use the .angular-cli.json file for info) Not sure if this would provide a solution that is maybe one better then a completely separate seed project?

ng new my-lib && ng-lib ./my-lib
rjcorwin commented 7 years ago

w00t!

@filipesilva Your documentation PR looks like a great start! It's too bad it's stuck behind the aio documentation site's infrastructure upgrade. I'm sure there is a lot of fuming all over this issue queue that will die down once it is published. I'm looking forward to https://github.com/angular/quickstart-lib being a thing.

@robwormald Thanks so much for pointing that PR out, not to mention the presentation at NG Conf about how to package an Angular Library.

@deebloo @hansl Can you point to some docs on how to create new generators in the Angular CLI? I'm interested in playing around with rolling the quickstart-lib into a generator.

@hansl For folks landing on this issue, it might help to point to the documentation PR even if it's not live.

gonzofish commented 7 years ago

@robwormald thanks for yet more thoughtful, well-explained responses

rjcorwin commented 7 years ago

For folks landing on this issue, it might help to point to the documentation PR even if it's not live.

By that I mean it would be helpful for the folks landing on this issue if the first comment was updated to summarize the efforts being taken.

yordis commented 7 years ago

@deebloo I wouldn't push for another command or any other tool that in the reality should live inside ng.

Angular team, Look your Polymer partners, they push for bower because of the limitation of npm and everyone hate it but at the same time just dont care because it works at the end of the day and they show you all over the place how to do it. No by reading 3 pages long of some specification or something like that, their strategy includes short videos and a lot of interaction with the community, documentation and so on, but also the tooling backup.

Some take away from there, is that you do not have to adapt to everything in the Javascript community but if you don't teach us how to be productive, care about us, how can we use Angular. I am fine with any architecture and ecosystem switch if I will be back up for the creators and I will find the answers without reading a technical paper (no because I don't know, which I am excluding the people that actually don't, but because that detail on my stack should be far away from me as possible, even Typescripts configs).

yordis commented 7 years ago

And btw, probably the information is there but we failed on put it out.

dherges commented 7 years ago

@deebloo that's the intention behind ng-packagr. There's also a demo showing ng and ng-packagr side by side

yordis commented 7 years ago

@dherges is this what Angular CLI uses? I am trying to push such of tool in the Angular core team. They should be doing that work, IMO

shlomiassaf commented 7 years ago

Hi guys,

Following a massive work i'v done to integrate a solid build process I recently converted it to a general purpose repository due to demand in our community.

After some exploration I found that these are the key features a library template should provide:

Some bonus features that are nice:

The simulation is actually a big deal, it enables running the demo app against a compiled, published version of the library where the demo can be JIT and then AOT. This is a good place to run E2E tests and verify that the publish (to be) version is legit.

The E2E unit tests on the demo app are more aimed towards the library ofcourse, not the demo app.

To make this work there are some changes needed in @ngtools/webpack. This mainly concerns providing hooks in the AOT plugin for integration.

I'v implemented this in ngc-webpack which is a light compiler-cli wrapper that allows these hooks. (ngc-webpack provides the AOT integration in AngularClass/angular-starter)

The plugin will notify when the AOT compiler loads a resource, this allows saving the resource for future inlining. (lib is built with skipTemplateCodegen false)

The huge benefit here is that we don't need gulp or any other process to manage our resources. They are handled natively** through the webpack loader chain we configured, this is a seamless process that ensures consistency. (think SCSS, postCSS, etc)

@hansl I know that @jskrzypek started talking with tou about that, based on the work I'v done in ngc-webpack, but he had to drop it due to other constraints.

All of the features I'v listed above (+ the demo and simulation) are part of the library starter repository I mentioned previously.

You can check it out in this repo: https://github.com/shlomiassaf/angular-library-starter

It is working great and there are examples there where you can see the output, its the same output as angular packages with support for UMD, FESM (es2015+5), tree shaking etc..

One good example to look at is a scope, multi-lib project with internal extensions (e.g. @angular/core/testing) which I call extensions / plugins.

Scope: @corp

There are 3 libraries and 2 extensions:

This is a good example since it demonstrates the capabilities for building a complex structure with inter-dependencies and how they are handled when bundling (rollup external and globals)

Frankly, I'm not a fan of starters if we can integrate it into the CLI, I would love to help getting it into the CLI.

cc @shairez

Edit: Theoretically speaking, if we achieve the above the angular project, material, etc.. can all use the cli, which is remotely similar to TypeScript written in TypeScript :)

gonzofish commented 7 years ago

@shlomiassaf I really like the idea of build hooks and the in-library scoping of packages.

Currently on Angular Librarian we have a lot of the features you mentioned plus some light scaffolding capabilities (initializing project, components, directives, services) and it'd be great to integrate some of those features in.

I know it's not the official Angular CLI, but I'm just trying to fill the gap in the meantime as best I can.

larssn commented 7 years ago

So I gave https://github.com/filipesilva/angular-quickstart-lib a shot. And after having spent a day playing with it, my conclusion is that it has a ways yet to go. It's a bit un-DRY, and I dislike the reliance on systemJs and Rollup. While Rollup might produce smaller bundles, I'm drowning in complicated techs that I don't have time to get fully acquainted with; techs that produce obscure errors, from time to time.

So my suggestion for people coming here looking for a module bundling solution, is wait a while longer.

Use npm link for now.

My 2c.

shlomiassaf commented 7 years ago

@larssn My guess is that these errors mostly concern the bundling, more specifically defining externals and globals.

IMHO, this will not change in a CLI implementation as well, you will have to provide proper configuration to your library build process.

While there is a high probability that external entries can be discovered automatically, globals are less likely, you'll have to provide them if you want UMD bundle support.

Anyway, building a library is considered advanced and some knowledge, I believe, is expected.

larssn commented 7 years ago

@shlomiassaf Yes, the errors were mostly related to that. I'd fix one, and a new one would pop up. The challenge I laid on myself was to have import support for json. Mostly got it working, except for tests, which is where I gave up for now. Might have been able to solve it; but a part of it was to review the work involved in quickly creating reusable libraries; a point on which I'm not convinced on.

shlomiassaf commented 7 years ago

@larssn That happens because you have to declare 3rd party imports. For each unique import token you need an external declaration, that's for FESM. For UMD you also need to declare the global name.

So, if you add import { Observable } from 'rxjs/Observable'; you need to make sure you declare

external: rxjs/Observable
globals: Rx

external is straight-forward, this is why it can be automated.
globals is custom, the way the author decided a UMD bundle will register in the global (e.g. window) object.

Other examples:

rxjs/operator/combineLatest - Rx.Observable.prototype

@angular/common - ng.common

Not so difficult to maintain, specially since rollup will notify whats missing.

dherges commented 7 years ago

For 9-out-of-10 libraries in the Angular world, these configurations can and should be provided w/ well-known values out-of-the-box.

A rollup config for rxjs and the @angular/* packages doesn't need to be copy-pasted from one seed to another seed to yet another starter... it can be simple, when we try to improve one step after another.

rjcorwin commented 7 years ago

Hi folks, I wrote up a proposal of how we can share Angular Modules right now between Angular CLI Apps. I call it NG Remix and it has two principles.

In my proposal I discuss how we can apply those principles, the pros and cons, and also include a specification for a ng-remix CLI that could help take out the manual labor. I'm interested in feedback from folks. Certainly those two principles won't work for everyone, but if it works for let's say 50% of the thousands of Angular developers I'd say it could spur a lot of sharing.

See the proposal here -> https://gist.github.com/rjsteinert/82b3000037a5672f43a4d15313ac613f

rjcorwin commented 7 years ago

@robwormald I'd be interested in your thoughts on comparing the seed library approach to the NG Remix approach I proposed above.

robwormald commented 7 years ago

@rjsteinert feedback:

I guess i'm not quite clear on what your approach is here?

rjcorwin commented 7 years ago

@robwormald

anybody who wants to consume your library has to be able to recreate the entire typesystem / environment on their end

That's what ng-cli is good at I believe :-). Being an angular-cli created app is a hard requirement and I could make that more clear in that proposal. That also now makes me realize that these modules will eventually need to specify the version of ng-cli they are based on. Note, to someone like me angular-cli is the Angular Framework. If a framework is a bunch of things strapped together, angular-cli fits that description better than @angular/angular.

Why does bower come into this?

Lol, ya, surprising. It was recommended by Rob Dodson presenting at Google I/O for use with Angular in the context of Web Components right at this point in the talk. The reason for this is "flat installing". Why would we for example want two different versions of the same module that define the exact same route? Bower helps you sort that out when two modules define the same dependency but at different versions.

rjcorwin commented 7 years ago

@robwormald Updates to your questions now added to the proposal. Thanks for taking a look!

dherges commented 7 years ago

The last few discussions here again stress the point in having small, focused tools do to the job. While seeds and starter packages are a nice thing, the questions is: how do they work together with ng CLI or custom webpack builds, or bazel, or how-does-YOUR-set-up-look?

Again, I think, it should be public_api.ts in and a dist folder in Angular Package Format out. As a good start, build and test should be the two commands to support!

# Build the library
$ <angular-library-build-tool> build -p <library-conf>.json
# Run unit tests from *.spec.ts files
$ <angular-library-build-tool> test -p <library-conf>.json

And it's definetly on the agenda for dherges/ng-packagr#5 next!

Flixt commented 7 years ago

Well, after reading through #1692 and this issue I'm totally puzzled what approach to use to currently create a library. To get the least problems as soon as the angular / angular-ci team comes up with their own solution. The most extensive approach seems to be the one from @shlomiassaf at https://github.com/angular/angular-cli/issues/6510#issuecomment-309702987. But I don't really need the "multiple libs in one repo" approach in my case (although I understand its existence).

So what to choose: https://github.com/filipesilva/angular-quickstart-lib or https://github.com/shlomiassaf/angular-library-starter or https://github.com/jvandemo/generator-angular2-library or check out how they did it: https://github.com/ng-bootstrap/ng-bootstrap

And if you just try to find a solution on the internet (like most people will do) tutorials like http://www.dzurico.com/how-to-create-an-angular-library/ or https://github.com/tpadjen/tpadjen.github.io/blob/master/_drafts/publishing-an-angular-2-typescript-component-to-npm.md pop up.

It gets even more complicated when you have resources (scss and images) or want to build a library that itself depends on a library/framework like bootstrap or zurb foundation. I fully understand @oliverjanik in https://github.com/angular/angular-cli/issues/6510#issuecomment-305050324 and there should be some official response what to do to fill the gap.

devoto13 commented 7 years ago

@Flixt See this talk from ng-conf for the most basic setup. Example from the talk is also available on GitHub, so you can take a look. It is not fancy (doesn't have many things you would like to have), but it works and let's you get started quickly.

gonzofish commented 7 years ago

@Flixt I want to point out that https://github.com/gonzofish/angular-librarian is also out there--similar to generator-angular2-library

It's a WIP, but it's been working for my day-to-day

kkganesan commented 7 years ago

@devoto13 How do you handle external templates inside components ? simple-ui-lib mentioned in the talk uses inline templates.

devoto13 commented 7 years ago

@kkganesan Currently I use only inlined templates and styles. Not very convenient option, but it works for now.

anjmao commented 7 years ago

I like how https://github.com/filipesilva/angular-quickstart-lib is made because it builds library to correct angular module format and it has integration tests running in jit and aot modes, but it uses crappy SystemJs. I rewrote development build process to use Webpack for demo app and unit tests in this simple library project https://github.com/anjmao/ang-select.

piernik commented 7 years ago

@robwormald any update on this?

nekkon commented 7 years ago

Hey guys. Just wanted to share with you a solution which suits the company needs I am currently working. I managed to make cli work as a mono-repo with multiple apps and a shared library of modules. The current setup supports lazy loading, AOT, SCSS and a custom path ("@shared/") for my shared modules. Although this setup is considered a hack and probably does not follow the Angular Package Format , it does suit our needs. It is simple and easy to work with as you can have multiple apps that can be served/built independently that share your custom components and the same node_modules. The basic repo structure is:

A repo showing the setup after request: Github repo

I do want to thank the Angular team for this fantastic framework as I enjoy working with it everyday. Continue the great work guys :)

roni-frantchi commented 7 years ago

Thanks for sharing your solution @nekkon . Do you have a GitHub repo showing a setup of this structure?.

nekkon commented 7 years ago

I have updated the Github repo with more functionality after several requests:

Angular CLI with Library support (1.2.7)

This project was generated with Angular CLI. It is an extended version of a new app generated with ng new. It adds Library support for multiple apps in a mono-repo.

This starter is a result of many workarounds in order to make angular-cli work with a shared library of components/services/modules etc.

Currently supports:

Serving multiple apps at the same time Production build of multiple apps (with AOT) Shared Library of components/modules ( can be shared between each app with @shared/ ) Shared assets folder and polyfills. ( can be shared between each app ) Shared SCSS. ( can be shared between each app ) lazy loading of Shared modules Unit tests for each app E2E tests for each app Custom commands to make your life easier and everything else you would normally be able to do with an app generated with ng new. Feel free to create an issue for a request or to fix something.

Star and support this project if you like it, to help it stay alive and maybe even be added as a boilerplate/starter to angular-cli (e.x. ng new app-name --template library).

yordis commented 7 years ago

@hansl any updates from the Angular team on this?

nekkon commented 7 years ago

@yordis @piernik @desfero @RSginer @samherrmann @benjamincharity @gracegotlost @rafmagns-skepa-dreag Hey guys. Till the Angular-CLI team officially provides you with a library option you can try out library. Feel free to provide feedback, make requests or report issues. I will be updating it constantly cause I use it at work. (current version 1.3.2)