[RFC] Library Support and Boilerplate Comment Thread

[hansl]

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

Continue the conversion here.

[dherges]

@nekkon Just to unterstand ... angular-cli-library shares common code from TypeScript sources with a compilerOptions.paths mapping, right? So in effect, each app links against sources and re-builds the shared library. The shared library is then not intended to be published on a npm registry, right?

[nekkon]

@dherges "angular-cli-library shares common code from TypeScript sources" -> Yes. It uses modules/code located in the src folder, either in your app or from a library (shared code). The library can also be published on an npm registry if you want to. I could add an example to the repo. Because I do not want to pollute this thread, please provide feedback, ask questions, make requests or report issues in the repo

[dherges]

@nekkon Yes and no. If published to npm registries, it should be in the Angular Package Format and this involves a series of different build steps and tools.

[nekkon]

@dherges The library can be published to npm registry. I have added an example where the shared library is imported from npm registry (Example2). Imported modules can be lazy loaded in other projects and are aot compatible. From my understanding, this thread is talking about a library that can be imported into other projects. I do not understand you. Why does a library need build steps and tools?

[yordis]

@nekkon would you create some video explaining how to use it and you can add to the video some questions asked already? Some people like me are more visual, just asking, no a big deal

[nekkon]

@yordis I could do something like that but it would take me some time to make the video. I'll try to find some time during the weekend.

[dherges]

Fine!

I was mainly speaking about angular package format which is the recommended way of publishing a library - as opposed to publishing source files leaving the typescript compilation, template syntax & type checking, styles preprocessing like vendor-prefixing or scss/less preprocessing to the build tool of the lib consumer.

Cheers, David

On 24. Aug 2017, at 22:44, Nektarios notifications@github.com wrote:

@dherges The library can be published to npm registry. I have added an example where the shared library is imported from npm registry (Example2). It can also be lazy loaded in other projects and is aot compatible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[nekkon]

@dherges Thanks. I will add what you mentioned is missing ( typescript compilation, template syntax & type checking, styles preprocessing like vendor-prefixing or scss/less preprocessing ), although it can be used for most use cases as it is.

[intellix]

When people talk about adding library support, they're usually talking about a pre-compilation step and consuming it like that.

Just want to add my use-case that we need shared code that isn't pre-compiled. We want to be able to provide Core components that consume Images and SCSS variables. Depending on the app served, the SCSS variables provided to those Core components will be different.

We have a white-label website and then we have around 10 "skins" or "brands" or "themes" that only need to change the colours and images. Imagine you need to create 2 applications: "Coca Cola" and "Pepsi". The only thing that changes is the colours and images. We could achieve this with the monorepo stuff though I think

[about-code]

@intellix I recently experimented with project scaffolding for an Angular monorepo. The generated projects have a structure similar to the Angular repo or the structure proposed by Lerna, thus facilitating

• building libraries in a monorepo
• building apps from feature packages

I've outlined my main motivations for a monorepo approach in #6083 but repeat some here. (edit: see better explanation below)

@intellix I, too, consider a theme to be a separate package for the same reasons you mentioned. When generating a project you can choose to scaffold a theme-package, too.

From what I've seen so far I can recommend ng-packagr by @dherges to build packages conformant to Angular Package Format (no enterprise experience here, though).

[intellix]

TypeScript just pushed a fix for symlinked repositories containing a node_modules and not being able to resolve types as being the same: https://github.com/Microsoft/TypeScript/pull/18185

I pushed the 2x repositories that work with both angular@next and typescript@next:

• https://github.com/intellix/angular-cli-red
• https://github.com/intellix/angular-cli-blue

Blue CLI depends on Red CLI and uses a component from it. I just referenced angular-cli-red locally since they're not published: "angular-cli-red": "file:../angular-cli-red" so checkout next to each other like:

angular-cli-red
angular-cli-blue

[nikolasleblanc]

Potential solution until the CLI starts being able to build out component libraries thanks to @dherges's ng-packagr: https://medium.com/@ngl817/building-an-angular-4-component-library-with-the-angular-cli-and-ng-packagr-53b2ade0701e

[jimthedev]

@nikolasleblanc This is fantastic as a stop gap. Any chance you've used a monorepo setup like lerna with this config?

[gonzofish]

I've said a couple times in this thread (and I hate self-promoting, but here I go again) I've been working on a project called Angular Librarian that has worked pretty well for my team.

It has all of the scaffolding you'd expect from the CLI and bundles using the Angular Package Format. I'm trying to make it so monorepos can work out-of-the-box.

I really respect what @dherges has done with ng-packagr and it's integration with the CLI, but always want to give people options!

[jimthedev]

@gonzofish Any chance you and @dherges could work together to merge those projects?

[gonzofish]

That's probably the best solution, isn't it? I'd be game and I think integrating with the CLI might be a more ergonomic choice

[jimthedev]

@gonzofish Seems like a solid good goal but also sounds like CLI might change to integrate with DevKit so does integrating with it in its current state mean things get pretty brittle? I can't find it right now but I think the Angular team might have indicated to @dherges already that they weren't interested in landing this in 1.x either. I don't know the answer so would love to hear what Librarian and ng-packagr currently do and what the differences are. @dherges might have to give us some insight into his goals / tradeoffs he's run into. Anyhow I don't want to be the middleman unless the two of you would like it. As someone who is hoping to use these I can see how some consensus would help in an otherwise fragmented environment when it comes to packaging Angular libraries pre-devkit.

[dherges]

Here's a design doc for the motivation of the tool and the purposes of ng-packagr. Think of it as (entryFile: TypeScriptSource) => AngularPackageFormat. You can integrate it with any other build tools around. There's no official support for it, but the GitHub issues are also a source of documentation.

Angular CLI has library developer mode for one year now, well in the announcements. I have no "stake" in Angular CLI and cannot speak for the Angular team. I do not know what their plans are. I just speak about my highly subjective perceptions :-)

When you run several dev teams at different locations, you appreciate to have a common tool chain. Eventually, Angular CLI helps us out a lot for building apps. No one wants to maintain highly customized build scripts in more than {{pick an arbitrary number now}} source code repositories. For libraries we now have a solution, too. We can perfectly live by an opinionated tool and its several best practice configurations.

[orizens]

I published 3 npm packages using https://github.com/robisim74/angular-library-starter as a starting point. https://github.com/orizens/ngx-infinite-scroll https://github.com/orizens/ngx-typeahead https://github.com/orizens/ng2-youtube-player

It's:

• AOT friendly
• supports ES5
• Support UMD bundles
• easy to publish to npm

[sparty02]

Nx looks like an interesting solution to this:. https://blog.nrwl.io/nrwl-nx-an-open-source-toolkit-for-enterprise-angular-applications-38698e94d65

[Matmo10]

Nx looks cool and all but I don't think its trying/meant to solve the library issue at all. It's really just putting everything into a monorepo so that you don't actually have to solve the library issue, right? Putting your whole company under one repo simply isn't going to work for a lot of organizations. Too many teams/people and releases to manage, and too much politics involved. This issue is more for generating standalone libraries that can be exported (and pushed to npm, for example) and imported into other apps (in other repos) - all while doing it with best practices (bundling, minification, etc), and supporting the developer experience as well.

[avatsaev]

True, Nx is a little bit of an overkill, plus almost nobody does mono-repo projects, except some huge enterprises. We just want Angular CLI to initialize a project in Library mode, that would be so nice.

[about-code]

Putting your whole company under one repo simply isn't going to work for a lot of organizations

nobody does mono-repo projects, except some huge enterprises

@Matmo10 @avatsaev I think you miss the point. Monorepos might not be necessary to build a library. But I think they are important beneficial to how libraries will emerge as part of an app development process. I find that Nx describes pretty much the same story I isolated from my own experience and consolidated here and here.

Monorepo doesn't necessariliy mean to develop all libs of a company in one giant repo (although Google, FB, etc. are said to do so) but also to develop one application from multiple smaller packages in the same repo. App development and library development are two sides of the same coin, I think. Done right, application development is a process of incubating new and reusing existing libraries. And even small companies develop large apps (should better say applications) and need to practice reuse to be competitive. They need to keep building blocks simple and focused to grow their system without growing the mental overhead to understand it on the same scale.

So let's assume collegues from another project asking you if you have solved the logging problem for your app. I can imagine teams which say, yes we have solved it. Just copy our sources. And I can imagine teams which say, yes we have solved it. Just run npm install foo-logging (much more appealing). I can even see the same team copying things around for the Next-Important-Big-Customer project and I can imagine the same team just installing their own logging-lib from the last Important-Big-Customer project.

With Angular and Angular-CLI as of today, unfortunately, I have seen a lot copy-cats beginning to fiddling around with relative import paths extracting the logging services, ngModule and other stuff out of their CLI-generated app once someone asks for reusing this and that. They might not like a monorepo approach and then decide to put the logging parts into a separate repo, okay. The question is why haven't they done it from the beginning?

In my experience - you won't get people to think modular if your project structure encourages a monolith and with costs for modularity as high and complex as they are today. If people have to set up and checkout separate repos for each package, if they have to set up build scripts for each package even more so since building a lib for angular is such a pain, then they simply don't do it early enough. Modularity will be an afterthought. Cutting a monolith into modules is ways harder than doing it right from the start and usually even more than just copying things around (unfortunately, YAGNI always sounds pretty cool unless you find out what N really means and how it relates to Spaghetti).

So you want to develop an application from packages but you don't want to necessarily spread the codebase in as much repos as you might happen to have packages. That's where a project can benefit from a monorepo structure. If it contains a package useful to other teams, then you might decide to move that package into a separate repo at some point in its lifetime. E.g. if you want to spread maintenance efforts accross all teams using the lib (company culture!). However, the first important thing is to imagine this specific package, the second is keeping costs of realising it small and only third step is to moving it into another repo. Monorepos help with all three points. For the third step: you don't have to adjust a mass of relative paths when you always imported foo-logging by its package name rather than its location in your repo. If you have always imported your own packages like an ordinary npm package, then moving it in another repo is peace of cake with minimum impact on the incubator app!

Said, this I think monorepo support is not a must have for library support, but it does definitely assist in library emergence as part of an app development process.

[dherges]

One does not need a monorepo at all! 💯

One could even publish npm packages to private git repositories and npm install | yarn install from git urls! Even angular does for their builds

[about-code]

One does not need a monorepo at all! :100:

@dherges Even though writing about benefits of monorepos I can support that. Being able to make a script iterate over a package folder during build like with ng-packagr is just enough for me at the moment :smiley: (optimized version supporting scoped packages here).

[adamlubek]

I don't think it's been mentioned here but according to official blog post https://blog.angular.io/the-past-present-and-future-of-the-angular-cli-13cf55e455f8

Future of the CLI The team working on the CLI has a lot of plans for making developers’ lives even easier. Here are a few of the ideas the team hopes to (but doesn’t promise to) include in future releases: [....] Library support — Today the CLI can produce UMDs optimized for the browser, and CommonJS bundles optimized for the server. What if the CLI could help you produce a bundle that could be consumed by other Angular applications? [...]

[petersalomonsen]

We're in the process of making a simple command tool for generating libraries. You just pass the ts-file you want to be the entry point of the library:

ngmakelib src/library.entry.ts library-name

and this creates a tar.gz that you may use directly with npm install.

Currently only exporting FESM module which works for all our usages for reuse in other Angular projects.

By installing this tool in your CLI project you may export it as a library to use in other projects.

You can take a look here: https://github.com/fintechneo/ngmakelib/

[avatsaev]

https://github.com/dherges/ng-packagr does that with FESM2015, FESM5, and UMD formats, it's been broken in some uses cases, but the 4.4.5 release of Angular fixed the issue (https://github.com/angular/angular/pull/19579), the ticket was closed today, I've tested and it works great now https://github.com/dherges/ng-packagr/issues/101

[dherges]

There are a lot different aspects to Angular libraries.

1. Rob said to distinguish binaries and libraries - let's use this terms now!
2. Monorepos and Nx workspace do favour "libraries": everything is linked within a single source code repo, so every app can build the library from sources – also, this monorepo steam is trending… 🚂
3. Angular Package Format is for distributing "binaries" to npm registry: the library is build from source before publishing.

I'd say you need to answer first how your workflow is (or how you like it to be)?!

When you have that ... 🎉 , then the very last step is to decide what tools to use. There are a lot of and you have to decide how much you want to get into the details of the "fav tool of week"-thing 😂

Next question of interest: in what direction does the ng CLI want to go? Do they have plans for supporting Angular Package Format? Or is schematics / code scaffolding the primary way, thus telling and assuming to use monorepo? Is it a mixed approach?

[about-code]

@dherges I have great respect for your work and it makes me sound a bit like a smart-ass but I think you misunderstood what Rob meant when he wrote:

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

• a binary is a shippable-to-the-browser-artifact that's "self executing"
• a library is a designed to be consumed by binaries (or other libraries)

Maybe @robwormald can jump in if I am wrong. But I am sure building the library from its sources into Angular Package Format doesn't make it a binary in the sense Rob meant.

Angular Package Format is for distributing "binaries" to npm registry: the library is build from source before publishing.

Let's stick to the APF docs and keep saying its a format for distributing packages / libraries which support the most common consumption patterns as well as the additional requirements to be consumed by Angular apps. The term binary isn't used anywhere in the APF docs. APF-compliant npm packages don't need to be self-executing bundles shippable to the browser. In many cases they will be component libraries like Material UI which aren't ever meant to execute independent of an app. The app is the binary here.

Rob said to distinguish binaries and libraries - let's use this terms now!

He said at Google they do distinguish in the way cited above. I wouldn't read it as a recommendation to adopt Google-internal terminology but just as an explanation by Rob. The term binary isn't self-evident in the JavaScript context and without explanation is misleading at best. In the end I am pretty sure we can skip any "binary" wording when we talk about library support and I advocate to do so to avoid confusion.

[dherges]

It's my understanding of the terms "binary" and "library" (as mentioned by Rob) in the context of a mono-repo (as explained by Victor, and as example used in Nrwl nx workspace).

If I am mistaken, maybe Rob or Victor can help out. But it pretty much sounds like the above because a FESM bundle is self-executing in the browser. You cannot see any output, still you can copy&paste the JavaScript to the browser's console and it will execute the instructions. Also, UMD bundles and IIFEs are self-executing in that perspective.

[achieverprince]

This issue was created on May 31 2017, and we are still here without any official working solution :(

[rjcorwin]

@robwormald Are you referring to a super power of packaging Angular Components up as Web Components? https://twitter.com/robwormald/status/916748096511500288

If so, perhaps that's a major win for this issue?

[avatsaev]

I honestly believe that the absence of an easy and reliable solution to make Angular Libraries will drive developers away from the framework.

Right now there's a gazzilion different solutions, all of them shit the bed at some different corner cases, and Angular CLI still can't offer a reliable library mode. I've been Angular dev from the first Beta and this is what frustrates other devs and me the most.

Making a tool to easily build angular libs should be NUMBER 1 PRIORITY right now, not Angular 5, not Angular Universal, not RxJS 5.5/6 compatibility, not PWA, but Angular component libraries.

[intellix]

Nx workspaces are quite brilliant. I've got an example that uses multiple apps with lazy-loading and core modules etc: https://github.com/intellix/nx-cli My last problem now is that compiler-cli doesn't like that a Component can be declared in 2+ modules which can happen if you need to replace a component by importing only the components you want.

[nikolasleblanc]

@avatsaev That seems unnecessarily harsh.

There are tons of Angular libraries that already exist, created by developers that had to work hard to figure out how to create component libraries the hard way. Thanks to their efforts, there are tools that exist to try to make developing these libraries easier. If these tools are "sh*tting the bed", it's because they need help. So identify the problem, submit a PR, and fix it.

When the CLI's ready to officially support libraries, we can all shut this down and move on, but until then, let's suck it up and help each other out.

[gonzofish]

I know I'm always up for a PR on Angular Librarian and I doubt any of the other solutions are adverse to positive contributions to their projects as well

Thanks for saying that @nikolasleblanc

[alexeykostevich]

Looking at @filipesilva 's response for #8284, I've realized that Angular CLI doesn't work with libraries in TypeScript out of the box.

@filipesilva, I would like to thank you for explaining the issue and providing the workaround. In addition, I would like to explain my situation in more details.

Our team has faced the same issue as @rolaveric . We are building a product suite, which is made up of smaller applications for different domains. Since all apps follow the same design guidelines, we have a library with reusable shared components.

Actually, we do not have the team dedicated to library development. It is used just as a container for reusable code that can be referenced from applications. So, our library is not a standalone project and makes sense only within apps.

Our team considers TypeScript as a first-citizen programming language. It means that all development is carried out in TypeScript, and all repositories use the same TypeScript version and configuration. Taking this into account, we made a decision to ship our shared library just in TypeScript to avoid extra complexity.

I understand that we are doing this at our own risk and violate the Angular package format. However, since Angular CLI does not provide a solution at this point for libraries, this approach helps to avoid extra complexity of configuring and maintaining a custom build process for libraries. Moreover, this allows to dramatically simplify the application development process since we are able just to reference and test the library directly from the app, getting all benefits of fantastic Angular CLI features (e.g. live reloading) out of the box.

I admit that this can sound a bit hacky, but, from the other, side it helps the team to be focused on product development, but not the Angular build process.

Currently, we consider using the Nrwl Extensions for Angular, which looks really promising.

Does someone face the same issues? What approach would you recommend for such case?

• Use a custom build process (like ng-packagr)
• Use a mono repository with the Nrwl Extensions for Angular
• Ship TypeScript library and wait the official solution from the Angular team
• Something else

[about-code]

@alexeikostevich If you're in a closed company setting and might even have your own private npm registry then I'd say

• Ship TypeScript library and wait the official solution from the Angular team

is just good. We've been doing this for the last year and it causes the least trouble for us at the moment. Not publishing TS to the public npm registry is all about web standards (ECMAScript is a standard, TypeScript not), interoperability and ease-of-use (not everyone wants to set up a transpiler). If TypeScript is a defacto standard inside your company then nothing prevents you from publishing TypeScript packages internally. if it works for you just do it.

Nrwl/nx describes an important story (monorepos) in terms of angular app development in general and a story related to library development but not necessarily the solution. E.g. what I don't like about Nrwl/nx is that libs are scoped packages but the scope name is derived from the name of the workspace. So you can't develop packages with different package scopes in the same workspace. Since you say your libraries only make sense within your app a project-specific npm-package scope might be less of an issue to you. If you have a policy, though, that all packages must share a common company-wide package-scope then I guess with multiple workspaces all of these would have to be named identical or you really can have only a single workspace and repo where you develop all of your company's libraries.

Apart from that installing Nrwl/nx via npm didn't work when I tried it. I had to use their bash script install process. For my own purposes the missing flexibility in case of package scopes is a limitation and I posted an issue on this edit: but didn't get an answer so far and the situation is likely to be addressed in some future versions.

What approach would you recommend for such case?

I am afraid its not the answer you look for but in the end I'd honestly recommend to not wait for recommendations but just take an hour or half a day yourself to try Nrwl/nx and ng-packagr. I am sure you'll quickly find out yourself whether they suite your needs or not.

[alexeykostevich]

Thank you for the detailed response @about-code !

We really publish our TypeScript library to the private company NPM since the package is not compliant with the web standards, but it helps us to keep going with product development and stay productive.

As you suggested, we will definitely review currently available alternatives in the nearest future. It seems that we are walking on the thin ice, shipping the library in TypeScript, and this can prevent us from updating to the Angular/Angular CLI in the future.

I wanted to raise this problem since this use case should be pretty typical for enterprise development.

[neo]

Just wondering would it be easier to build something that could produce a library for only cli-based apps?

[petersalomonsen]

@neo Solutions for building libraries for consuming in CLI already exists - as mentioned above:

https://github.com/dherges/ng-packagr ( implements full Angular Package Format ) https://github.com/fintechneo/ngmakelib (minimum solution, not full Angular Package Format, but can be consumed in at least other CLI apps, ngc/rollup and SystemJS, I'm the author of this )

[gonzofish]

@neo although its build process doesn't directly leverage the CLI, my library, Angular Librarian, compiles to Angular Package Format

[ar-arkhipov]

Hello to everyone. I am really inspired by such tool like ng-packagr, mentioned above. I've built simple library example, which is based on basic angular-cli app and ng-packagr. It has preview app inside, supports demo/developer mode and can be easily imported into your running angular5 apps. I've also added compodoc and live-rebuild mode to make it a bit more cool.

Check it out here: https://github.com/Tamango92/yo-lib Read the docs (sorry in advance, I am not good in writing nice docs), feel free to rename lib in local package.json file and replace all 'yo-' prefixes with your own.

[about-code]

@alexeikostevich

It seems that we are walking on the thin ice, shipping the library in TypeScript, and this can prevent us from updating to the Angular/Angular CLI in the future.

I am less concerned about this, actually. TS is pretty stable in terms of backwards compatibility. The only thing you need to make sure is that your libraries don't declare TypeScript as a hard (dev-) dependency but as a peer dependency with a version range beginning with the minimal TS version the lib expects (based on the language features it uses) up to the next major version. If Angular requires a newer version of TypeScript then consumers of your lib can choose to install a newer or the newest TS version required by CLI and continue to use and compile your lib.

[matheo]

@about-code does angular/cli works ok with "Typescript libs"? If I understood correctly, you work with private Typescript packages, do you mind to share how to set them up? thanks for your time!

[about-code]

@matheo I am only using @ngtools/webpack regularly so can't speak about the CLI. But TS libs in the sense I understand them are just plain old NPM packages with TS sources rather than JS sources. They're published to an internal NPM registry untranspiled and when used get installed into node_modules of the dependant. They should have an index.ts at the same level of the package.json. TS implements the Node resolution algorithm and can find the index-file when it is imported via import { FooClass } from "package-name". The index file should (re-)export the public API of the lib - and only the public API. Try to avoid re-exports like export * from "...". TS libs when used in a TS app get transpiled with the app they're used in.

Once again I emphasize that TS libs should live in private registries and packages only. The NPM and node ecosystem shouldn't be polluted with TS libs as they aren't JavaScript and non-standard. Also note what @alexeikostevich wrote and the issue he linked. Some Angular-CLI contributors are heavily against TS-libs (see https://github.com/angular/angular-cli/issues/8284#issuecomment-341417325) so don't take my opinion for granted.

[neo]

@about-code should we build a registry together 😅 that's what I thought it could be too

[matheo]

@about-code I figured out a way to compile my library with ng-packagr but not setting up the CLI project on the root of the repo, but inside a subfolder. Then I compile the lib to /dist and reference it from the root package.json to be consumed by my other projects. I will share more about this setup after get working all my stuff. Thanks to all for the great work! :thanksgiving

[shlomiassaf]

Following my last issue comment...

I've done a lot of work on this and after analyzing my work I think we can split the problem into 3 parts, from which only 1 (number 3) is an issue related to angular:

1. Project management (file structure and setup)
2. Packaging / Bundling
3. Compiling

I'll write briefly on (1) and (2), (3) is the thing that requires a solution right away.

Notice that (1) and (2) are not unique to angular, any framework or library or vanilla project will have to address these issues.

First some key points:

• @ngtools/webpack is not related to this process, it bundles apps. For library compilation, we need to work with the @angular/compiler-cli.
• Webpack can be used to compile resources only (not drive the process nor bundle). This will yield similar results for dev environment and enables usage of the loader configuration we already have!!!

Project management

Angular CLI does this already but for applications, not libraries. A library needs a demo app for integration tests and easy development... This means that any project is a mono-repo... This is not trivial, proper setup requires advanced configuration of typescript and webpack.

For now, Nx workspaces provide a proper solution.

Packaging / Bundling

This is the process of taking the compiled output (JS) and packaging it into a format/formats. Angular has a spec for that, creating bundles in FESM ES2015, FESM ES5 and UMD along with d.ts files and metadata.json files. This is quite technical and already done properly in several projects (material2, ng-packager, angular-library-starter)

This is an external process, it can be done in the cli or by a different package through @angular/dev-kit via separate config files. Because solutions exists we can use them for now. It is purely an implementation and definitely not the problem.

Compiling

This following might be verbose and complex, apologies :)

Compiling is taking the TS files and compiling them to JS files. This is fairly simple with TypeScript (tsc) but get's complicated when using the angular compiler (ngc) The pain point is resources (html, scss, etc):

• The angular compiler knows how to handle HTML and CSS only, al other formats (SCSS, LESS) will not work.
• The compiler will not inline resources which are required for libraries.
• Resources appear in 2 locations, JS output and metadata.json files emitted by the AOT compiler.

ng-packager solved this issue using external process and post-processing scripts, it means using different tools then your development environment (dev use webpack, post-process use gulp tools) and doing it externally instead of part of the compiler.

The @angular/compiler-cli packages is extensible, it can be thought how to load resources so they are loaded as part of the compilation process (no post-processing, native inlining). The problem is that it is missing an async API required for loading resources via webpack (see angular/angular#20130) Once this is fixed it should be easy to do so (it can be done know by creating the API locally, everything requires is available)

By creating a CompilerHost and passing it to angular, we get control over resource loading, the compiler host is the loader of resources (among other things). Now, all we need is a way to use webpack to compile resources only within the compiler host and return them to ngc. We also add custom transformers to inline all resources on the fly and that's it!!!

For this we need to have an API in the CLI that creates a webpack configuration for us (at runtime) and stops (not building an app), from there are can create a webpack instance and create a compilation that can compile resources.

It might look complicated but I already have a working POC that apply a patch to the cli that allows extracting the config, from there it run's the compilation with a native resource loading through webpack. The result goes through rollup and creates the bundles.

The compilation step is done without extra logic or complicated addition to the cli.

@filipesilva @hansl If it's possible, can we discuss it and I'll come with a proposal that will only allow integrating the compilation step (no bundling, no rollup no nothing). This is a first step that will break the compilation barrier allowing ngc output that has resources inlined and compiled through webpack with cli configuration.

This is a logical flow:

• Call CLI API to get webpack config object for a build state (build, prod, dev etc...)
• Use custom compiler host that has a webpack resource loader loaded and ready to compile resources through the loader chain.
• Call performCompilation (async version) with the compiler host and an inlining transformer.
• Output is ready for bundling