New issue

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

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

Already on GitHub? Sign in to your account

Tracking issue: Angular BuildTools Convergence (ABC) #19058

Open
alexeagle opened this Issue Sep 5, 2017 · 35 comments

Comments

Projects
None yet
@alexeagle
Contributor

alexeagle commented Sep 5, 2017

We are open-sourcing the toolchain we use internally at Google to build Angular apps at scale.

One-pager: http://g.co/ng/abc

This issue will be used to give updates on progress.

FAQ: how does this relate to Angular CLI? We will evaluate this toolchain with some early adopters first, if it goes well, we will evaluate whether to use it inside the CLI. So long as you haven't ejected from the CLI, such a change should be transparent to users.

@alexeagle alexeagle self-assigned this Sep 5, 2017

@zh99998

This comment has been minimized.

zh99998 commented Sep 6, 2017

sounds like a big news.
will angular-cli moves to ABC and drop recommend of current webpack-based build system ?

@realappie

This comment has been minimized.

realappie commented Sep 6, 2017

Looks promising !

Is this going to kill the angular CLI? And will it eventually be a drop in replacement for codebases built with the angular CLI?

@mlc-mlapis

This comment has been minimized.

mlc-mlapis commented Sep 6, 2017

@realappie Angular CLI is a top layer so it should not be affected a lot but some changes probably could be.

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Sep 6, 2017

Updated the description above. It's possible this could be the build system in the CLI one day, but too early to be sure.

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Nov 21, 2017

Update: we are starting to accept enterprises in an Early Access Program, to try this out with support from our team.
If you are willing to tolerate risk, missing documentation, and commit to giving feedback, then we'd like to have you use this soon. Fill out https://goo.gl/forms/Tv8lMdH0N3D4yo8Q2 and I'll get in touch once we are ready to support your use cases.

@crutchcorn

This comment has been minimized.

crutchcorn commented Nov 21, 2017

Is there any way for individuals to sign up for this program rather than corporations?

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Nov 22, 2017

@GoNode5

This comment has been minimized.

GoNode5 commented Nov 22, 2017

@alexeagle could you define in time/seconds what you think is a slow build. The fact that the Angular platform degraded JIT, to a old fashioned build/compile/link time experience, even with small projects, I don't know what to expect. The reason I chose Javascript is because of JIT, wich I don't enjoy anymore in relation to Angular. AngularJS jit was F5 refresh build. Now ng build --prod is something to execute is low as possible, even with 'small ish?' projects.

@schmitch

This comment has been minimized.

schmitch commented Nov 22, 2017

I doubt that AnulgarJS jit was F5 refresh + build.
Either your browser loaded for some seconds or it took at least seconds to actually concat all the files.
AOT is the same, than any concat, just that it is more clever which will reduce the browser loading time.

@mlc-mlapis

This comment has been minimized.

mlc-mlapis commented Nov 22, 2017

@GoNode5 ... actually you can have dev time which is < 1 second = you just don't wait at all.

Another story is the whole building process to produce a completely new build for production or testing server (which is just internal version = the last step before production).

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Nov 23, 2017

Our goal is <2s dev roundtrip (50%ile) for a large project, O(thousands) of source files.

@GoNode5

This comment has been minimized.

GoNode5 commented Nov 23, 2017

@schmitch You can doubt what you want, just look at a hello world ng serve size Angular project...

Compared that to my AngularJS project F5 (cache disabled) . I could add 600KB Angular Code but that wouldn't change much. The show load in image is a full project with about 30 screens, multi language. The thirdparty libs take's most of the load.

image

With runtime / ng build -prod, I'am very happy with the 'end' result. Fast, small en stable. But my developers experience is ruined. I had to buy a faster computer, create strategy's. In a larger project it's not only the ng serve rebuild time, but the runtime compile feels also slow.

For me the whole JIT experience is gone while developing.

@schmitch

This comment has been minimized.

schmitch commented Nov 23, 2017

61 requests means that your project was really really small.
if you used systemjs and had 61 requests in a typical angularjs project it means you basically created hello world.
the other route was gulp/grunt and concat everything even that took a while for a decent sized project (more than 200 files js+html)
btw. our angularjs app only had 6xx files with 30k loc. it's now a hybrid app. loading barley changed.

still around 5s or more while on a clean site over 30 seconds (same happend on angularjs) if we tried out systemjs it was painful, because we didn't had any lazy loading at all so it loaded 500 files that was damn painful.

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Dec 13, 2017

Update: we now have a basic devserver ready to try out. I updated the README: https://github.com/alexeagle/angular-bazel-example

The purpose of this devserver is:

  • make a very easy getting-started experience, where you just add a ts_devserver rule that points to your app sources
  • a reference for benchmarks, because this devserver just concatenates the JS sources it scales very well

Much of the smarts are actually in ibazel, so it will be pretty easy to swap it out for some other devserver, like webpack, express, or even your Java or PHP backend, etc. We will write some documentation about how to make those other devservers work with ibazel.

Thanks to @gregmagolan for most of the work here.

see the earlier comment if you would like official support for using this.

@mattem

This comment has been minimized.

mattem commented Dec 13, 2017

@alexeagle That's awesome! My team has already signed up the EAP, and I will definitely explore the example you published further.
A few questions from a quick glance through it.

  • Is there support for using templateUrl instead of having the template inline for the component?
  • Using a reference to the sass file in styleUrls instead of the generated CSS file. Some IDEs (Webstorm for example) have editor support for clicking through to the file there, which is lost when using the css extension.
  • Rewriting the main.ts file to automatically include the import and bootstrap of the AppModuleFactory (like the angular CLI), same as the point above really, the editor picks this up as importing a file that does not exist.
@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Dec 13, 2017

Yes, templateUrl works just as well as template. This just runs ngc so all the usual caveats apply from Angular development in some other build toolchain like the CLI.

The styleUrls is a good point. It's subtle, because we don't want to magically re-write the file, and by the time Angular's compiler sees the component, there is no longer a .scss file to read. I think the best solution is to omit the extension on style files, just as we do for referencing .ts vs .js files. It means tools would need to know to look for both, and that means we'd need editor support to evolve. It's a stretch.
The simpler answer is to teach Angular to look for foo.css if it can't find foo.scss but I think this isn't a general solution because the scss_binary rule can produce an output file with a different name from the input.

Importing generated code looks strange, but this is idiomatic in Bazel, and it's what we do internally at Google. However, this particular problem will go away in Angular 6 - the plan is that the factory will be emitted as a static property of the Component class, and so you'll be able to just import the component and we'll know how to resolve the factory from that at runtime.

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Dec 15, 2017

It's a big week for ABC launches - we now have browser unit testing using Karma included in the example app. See the spec file

https://github.com/alexeagle/angular-bazel-example/blob/master/src/hello-world/hello-world.component.spec.ts

and the test target

https://github.com/alexeagle/angular-bazel-example/blob/c0fec902ce74e2ee00b194c7fad9fb5e056a4050/src/hello-world/BUILD.bazel#L37-L45

I also did a major pass over the documentation, adding the devserver, karma testing, formatting, CI, and more. https://github.com/alexeagle/angular-bazel-example/wiki

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Jan 29, 2018

Another launch announcement: we have a rollup_bundle rule you can use to create a production bundle. See https://github.com/bazelbuild/rules_nodejs#bundlingoptimizing for the doc and https://github.com/alexeagle/angular-bazel-example for an example usage.

At this point we are just missing code-splitting/lazy-loading and Windows support, to have feature parity with Angular CLI (for features I'm aware of :) )

@artaommahe

This comment has been minimized.

artaommahe commented Jan 29, 2018

At this point we are just missing code-splitting/lazy-loading and Windows support, to have feature parity with Angular CLI.

what about webpack features like inlining images in ts-files via require + loaders?

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Jan 29, 2018

@artaommahe good point, there's probably a long tail of features I'm not aware of. We have solutions for all these things at Google so it's just a matter of finding the idiomatic way to do it, and measuring the demand for which features to add when.

@schmitch

This comment has been minimized.

schmitch commented Mar 2, 2018

Does this use Closure for the end bundle or still use js tooling?

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Mar 2, 2018

The canonical example currently uses Rollup/Uglify, but we also have a work in progress to use Closure Compiler, and I've seen some examples of using Webpack.

@hiepxanh

This comment has been minimized.

hiepxanh commented May 5, 2018

hello, is anything update on this?

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented May 7, 2018

Sure, thanks for the reminder @hiepxanh - here's an update:

  • Angular, Angular Universal, NgRx, and Tsickle all switched to Bazel as the build tool, and ship Bazel-built artifacts to npm
  • I met with a couple enterprise users who have already adopted Bazel for some of their Angular projects.
  • Angular Material is almost ready to switch as well, we have one more bug to fix
  • We are working on a re-vamp of the Sass rules, which will bring them into alignment with Google-internal usage.

At ng-conf last month we had two presentations:

New features:

@hiepxanh

This comment has been minimized.

hiepxanh commented May 8, 2018

thank you so much 😍 , that is a lot of information. I will enjoy it just like my favorite movie series and waiting for team's full release 😸

@istiti

This comment has been minimized.

istiti commented May 8, 2018

Someone brave writed or is able to write article how to move from existing cli project with lazy load module to bazel build system ? 😬

@martyganz

This comment has been minimized.

martyganz commented May 8, 2018

@istiti please see the new features part of @alexeagle's comment up here.

He linked this: https://medium.com/@gregmagolan/production-code-splitting-with-bazel-8a7da242bf83

Looking at Alex's example repository will maybe also help you get started: https://github.com/alexeagle/angular-bazel-example

But please keep in mind that Bazel still might have breaking changes whereas your cli setup will work out of the box :).

@istiti

This comment has been minimized.

istiti commented May 8, 2018

@martyganz obviously already checked that 2 months ago, thanks but still out of scope to move from cli project. But you are right I should wait for ng add @angular/bazel

@johnbendi

This comment has been minimized.

johnbendi commented Jul 4, 2018

sandbox symlink to execroot does not include ngfactory files. More specifically, ngfactory and ngsummary files exists for material module at execroot but only ngsummary are symlinked into the sandbox which leads the build to fail with:

: Error: Could not resolve ./index.ngfactory from /home/johnbendi/.cache/bazel/_bazel_johnbendi/a78f499bf50e18fa3ff9c74610609e4a/sandbox/linux-sandbox/15/execroot/betadeals_frontend/node_modules/@angular/material/card/typings/index.d.ts
: Cannot determine the module for class AppFooterComponent in /home/johnbendi/.cache/bazel/_bazel_johnbendi/a78f499bf50e18fa3ff9c74610609e4a/sandbox/linux-sandbox/15/execroot/betadeals_frontend/src/ts/ng/client/app/components/app-footer/app-footer.component.ts! Add AppFooterComponent tothe NgModule to fix it.
@mattem

This comment has been minimized.

mattem commented Jul 4, 2018

@johnbendi I experienced the same issue, opened an issue in the example repo but haven't had anything back yet.
alexeagle/angular-bazel-example#159

@alexeagle alexeagle changed the title from Tracking issue: Angular, Bazel, and Closure (ABC) to Tracking issue: Angular BuildTools Convergence (ABC) Aug 7, 2018

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Aug 8, 2018

Update time!

  • The early access program has kicked off with 8 enterprise users. We aren't looking to provide more direct support right now.
  • Early version of ts_auto_deps which automatically creates/maintains BUILD files in subdirectories
  • Angular rules now have API documentation. http://angular.github.io/bazel-builds
  • Protractor rule is available.

We are beginning serious design work on making Bazel part of the Angular CLI. As a reminder, this is not an alternative to Webpack. You can imagine Bazel as a layer sitting between the Angular CLI and calls to Webpack, avoiding re-doing the Webpack work where possible, and parallelizing Webpack via the DLLPlugin.

@glebmachine

This comment has been minimized.

glebmachine commented Aug 9, 2018

Jesus, can't wait for it!)

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Sep 11, 2018

Update for September:

We have a significant improvement coming soon in the internals of how we interact with the npm ecosystem that should help with performance and ergonomics, should be in the next update.

@alexeagle

This comment has been minimized.

Contributor

alexeagle commented Nov 16, 2018

Update from October:

  • Bazel is published on npm at https://www.npmjs.com/package/@bazel/bazel - as a result, installing Bazel is no longer a requirement. Our plan is that a developer either installs nodejs/npm/yarn, or Bazel, but no one needs to install both. As proof, Angular's own CI build now runs on a vanilla nodejs container. Note that the Bazel team plans to reduce the size of the binary.
  • The nodejs rules now create Bazel build files for each installed npm package. This means that individual Bazel actions can declare "fine-grained" dependencies on which npm packages they need, and makes builds faster by reducing how many input files are needed.
  • I gave a talk at AngularMix (it wasn't recorded). I demo'ed a side-by-side of building Angular itself both using local resources on a 16-core machine, and with a remote build execution farm. The latter is an order of magnitude faster. I also showed a preview of "builder" support for Bazel under Angular CLI - on Windows we can ng serve --prod and everything including lazy loading works, and runs on Bazel
  • @mprobst gave a talk about Bazel at Angular Connect, https://www.youtube.com/watch?v=Qb3tykleV_g
  • We are working on Schematics for using Bazel that will be part of the @angular/bazel npm package.
@mgechev

This comment has been minimized.

Member

mgechev commented Dec 13, 2018

Updates from November / early December:

  1. We have ng add schematics for Angular CLI. This feature is in a very early stage but it'll allow more folks to give a try building Angular with Bazel. Find the commit, which introduced the change here.
  2. It's possible to use remote caching with Bazel today! We enabled experimental support in the Angular repository. To reduce latency to the minimum, we'd strongly recommend having the cache in the same network. Check out the setup we did for angular/angular here.
  3. We published Bazel's BUILD file formatter and editor as an npm package under @bazel/buildifier. Here's the PR.
  4. Faster TypeScript compilation by caching of the ts.Program. For details see the commit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment