angular-cli: Rebuild extremely slow
-
OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?) Windows 10
-
Versions. Please run
ng --version
. If there’s nothing outputted, please run in a Terminal:node --version
and paste the result here: angular-cli: 1.0.0-beta.11-webpack.8 node: 6.3.0 os: win32 x64 -
Repro steps. Was this an app that wasn’t created using the CLI? What change did you do on your code? etc. app created with 1.0.0-beta.11-webpack.2 and later on upgraded to 1.0.0-beta.11-webpack.8 with appropriate changes.
-
The log given by the failure. Normally this include a stack trace and some more information. The slow behavious is observed when upgraded from 1.0.0-beta.11-webpack.2 to 1.0.0-beta.11-webpack.8
-
Mention any other details that might be useful. Slow behavious reproduceable in following repo: https://github.com/asadsahi/ng2fb-bootstrap
I have experience this on two operating systems, windows 7 and windows 10. Has anyone else experieced this? For me rebuilds are dramatically slow, taking roughly 7-8 seconds which on same machine with cli version webpack.2 was taking rougly 2-3 seconds.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 50
- Comments: 226 (93 by maintainers)
Links to this issue
Commits related to this issue
- chore(build): use cheap-module-source-map for dev Allows for faster builds, partially addresses #1980 — committed to filipesilva/angular-cli by filipesilva 8 years ago
- chore(build): use cheap-module-source-map for dev (#2619) Allows for faster builds, partially addresses #1980 — committed to angular/angular-cli by filipesilva 8 years ago
- chore(build): use cheap-module-source-map for dev (#2619) Allows for faster builds, partially addresses #1980 — committed to JJayet/angular-cli by filipesilva 8 years ago
- chore(build): use cheap-module-source-map for dev (#2619) Allows for faster builds, partially addresses #1980 — committed to angular/angular-cli by filipesilva 8 years ago
- feat(test): make code coverage and lint optional Partially address #1980 Close #1799 — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(test): make code coverage and lint optional Heavily inspired by @abner's work on #1799. Partially address #1980 Close #1799 — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(test): make code coverage and lint optional Heavily inspired by @abner's work on #1799. Partially address #1980 Close #1799 — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(test): make code coverage and lint optional Heavily inspired by @abner's work on #1799. Partially address #1980 Close #1799 — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(test): make code coverage and lint optional Heavily inspired by @abner's work on #1799. Partially address #1980 Close #1799 — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(test): make code coverage and lint optional (#2840) Heavily inspired by @abner's work on #1799. Partially address #1980 Close #1799 — committed to angular/angular-cli by filipesilva 8 years ago
- chore(build): use cheap-module-source-map for dev (#2619) Allows for faster builds, partially addresses #1980 — committed to splice/angular-cli by filipesilva 8 years ago
- feat(build): add sourcemap option Add `--no-sourcemap` option to `ng build/serve/test`. Disabling sourcemaps can help with build speeds. My tests on a medium project shoul a 11.5% improvement on ini... — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(build): auto generate vendor chunk Add `--vendor-chunk` option to `ng build/serve`. Enabling vendor chunk can help with rebuild speeds. My tests on a medium project show a 34% improvement on re... — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(build): add sourcemap option Add `--no-sourcemap` option to `ng build/serve/test`. Disabling sourcemaps can help with build speeds. My tests on a medium project shoul a 11.5% improvement on ini... — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(build): auto generate vendor chunk Add `--vendor-chunk` option to `ng build/serve`. Enabling vendor chunk can help with rebuild speeds. My tests on a medium project show a 34% improvement on re... — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(build): add sourcemap option Add `--no-sourcemap` option to `ng build/serve/test`. Disabling sourcemaps can help with build speeds. My tests on a medium project shoul a 11.5% improvement on ini... — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(build): add sourcemap option (#3113) Add `--no-sourcemap` option to `ng build/serve/test`. Disabling sourcemaps can help with build speeds. My tests on a medium project shoul a 11.5% improvem... — committed to angular/angular-cli by filipesilva 8 years ago
- feat(build): auto generate vendor chunk Add `--vendor-chunk` option to `ng build/serve`. Enabling vendor chunk can help with rebuild speeds. My tests on a medium project show a 34% improvement on re... — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(build): auto generate vendor chunk Add `--vendor-chunk` option to `ng build/serve`. Enabling vendor chunk can help with rebuild speeds. My tests on a medium project show a 34% improvement on re... — committed to filipesilva/angular-cli by filipesilva 8 years ago
- feat(build): add sourcemap option (#3113) Add `--no-sourcemap` option to `ng build/serve/test`. Disabling sourcemaps can help with build speeds. My tests on a medium project shoul a 11.5% improvem... — committed to BROCKHAUS-AG/angular-cli by filipesilva 8 years ago
Should this be bumped as critical? It seems to impede peoples productivity and maybe scare new comers to angular-cli.
@hansl just added a massive performance increase in https://github.com/angular/angular-cli/pull/4145.
For a brand new project, times for
ng serve
third rebuild are 65% smaller :On a medium sized project:
@mrlund yes it will be included in the next release.
I just discovered that the awesome-typescript-loader
forkChecker
option isn’t being passed properly, so it’s not forking and type checking is happening inline. ChanginguseForkChecker
toforkChecker
in the webpack config drops reload time on a pristine project from ~4sec to ~1.5sec for me. I’ll prepare a PR right now.@asadsahi @clydin that seems to be a very relevant improvement. I’ll add
ts-loader
to the list of scenarios I’m benchmarking as well.+1 Rebuilds are extremely slow for me on OSX 10.11.6
Same issue here.
We aim to please 😄
https://github.com/angular/angular-cli/pull/3943 should help with the rebuilds of global CSS.
Running
ng test
is excruciatingly slow. It takes quite some time to detect there are changes and then re-run them.New project with 79 tests:
Single/first run: ~90s Changes:: ~12s Changes after using for some time before it crashes:: ~20s
As @guiomie said, the numbers don’t add up for serving either:
638+10+1+3+200+1+17+121+149+3+6+18+78+83+3+6+1047 = 2384ms
but says6080ms
so seems to be3696ms
going somewhere else.+1, new to angular2. I really like how it was easy to get started, sadly, keeping going is much harder. Every time I modify a file and save, it takes more than 10 seconds before I can reload the browser and see my update. For web development, I can’t do this. Maybe I’ll switch to Angular2 JS.
Here is what I see in my shell on ubuntu:
Do the assets really have to be optimised every time even if none of them have changed? A better approach would be to somehow cache the optimised assets if we need tp rebuild them every time to avoid repetition of the optimization.
5269 ms to reload on simple changes on OS X El Capitan with clean
ng new
I am going to close this issue as we have done pretty much everything possible on our side to reduce rebuild time in development. We’re actively working with Webpack to improve performance on their side, and you should expect more as they release improvements on their side.
Hey all, I’ve been running some benchmarks with recently added features in the CLI master branch.
@ngtools/webpack
as the TS loader for both AoT and non-AoT builds, across the board improvement.--sourcemap
flag (defaults to true): uses sourcemaps on builds. Disabling it improves performance.--vendor-chunk
flag (defaults to true): separates all non source files intovendor.bundle.js
. Enabling it improves performance.You can see them below:
Baseline performance for
ng serve
, especially on rebuilds, should drastically improve across the board startingv1.0.0-beta.22
.Some users have also reported that turning off progress logging improved their build and rebuild times, but I could not verify that on my machine so I think it’s setup dependant. https://github.com/angular/angular-cli/pull/2858 lets you turn it off via
--no-progress
.P.S.: The medium project benchmark showed a performance regression for
--aot
builds, but we’re working on fixing it.@filipesilva I also noticed rebuilds are about two times faster when I upgraded from beta.16 to beta.17; with average of 4 seconds.
I’m still new to webpack world, so I don’t yet really understand how things work internally, but after a quick search I found https://github.com/TypeStrong/ts-loader/issues/78. Is this what’s slowing down CLI’s build process? I used custom gulp build process few months ago and had average 250ms rebuild times, so even 3-6 seconds with CLI is quite a setback 😭
Also, bit off topic, is it possible to isolate app code from vendor code in dev builds? Would that speed things up?
@filipesilva so downloaded the
angular2-webpack-starter
and quickly made our app work. Rebuilds take 1.5s-1.8s compared with 3.5s-17s inangular-cli
. The initial build (after the dll had been created in another build) took 17s. That is compared with the 45s-60s fornpm start
ing angular-cli.@hccampos Question is do we really need that strict checking all the time? IDEs do most of this already. I’ve been working on an app for past 3 months with 2-3 major architectural changes and quite large refactoring each time. After all that, building the same app with
isolatedModules
turned off this morning I got only one import error in obscureDevComponent
I rarely use.I think it would be good idea to turn on
isolatedModules
flag withng serve
and off forng build
and other stuff…Another update: moving to
webpack@2.2.0-rc.3
(https://github.com/angular/angular-cli/pull/3786) seems to have had roughly a 30% performance (1.69s to 1.3s) increase in rebuilds.BTW, The slow rebuild issue mentioned here was becasue I was using awesome-typescript-loader. ts-loader seems to be 4 times faster. Raised with awesome-typescript-loader owner to see if any particular option has been missed.
I also have a very slow “chunk assert optimization” step (~8s all the time even for small changes in one file). looking at https://github.com/webpack/webpack/issues/539#issuecomment-111275792 it seems it could be due to the source-map configuration chosen.
But now I realize, Webpack Dev Server keeps saying, nothing has changed, when in fact things have changed. Changes are not beeing picked up correctly. Am I missing something, or is this a new issue? When I quit devserver and ng serve again, changes are beeing picked up, automatic rebuild says “Nothing has changed” in the browser’s console. So it recognises that a file has been saved, but sees no difference. Changes in the html templates are considered, changes in my typescript files are not.
Try 28 guys. I’ve just compared my large project before and after and it’s so much faster than 40% as advertised.
b26: 3.3sec average on save b28: 1.0sec average on save
Also for those that were looking at DLLPlugin, our attempts show that it’s currently not possible to use together with lazy route detection.
@intellix @MickL I haven’t looked at SCSS much yet but will.
Guys, Having stats of roughly 2-3 seconds as rebuild time with angular-cli@beta22 on a beefy machine using ng serve --no-sourcemap --hmr -e=dev-hmr. Without sourcemaps? Really?
My personal opinion is that it is still not the ideal time we should be looking for. DLL is the only way out of having rebuild less than ~0.5 seconds to improve developer productivity. As I mentioned in few of my earlier comments that I have ~300-400ms as rebuild time in a non-cli project using(webpack2@beta27 with DLL). And this is with cheap-module-source-map enabled.
@intellix
With ts-loader:![image](https://cloud.githubusercontent.com/assets/3470892/20273985/1c5f2b18-aa8b-11e6-82ec-d6d1f30f498e.png)
With awesome-typescript-loader:![image](https://cloud.githubusercontent.com/assets/3470892/20274107/6892a87a-aa8b-11e6-8cde-418b0baac4a8.png)
@rand0me as you just introduced me to Brunch and it caught my attention while looking at your stats. I tried this repo with angular and here are my stats:
That is Nitro fast. 93ms with a html change and 106 ms with a typescript change.
Will it be correct to say that Brunch is on top of the list for recompiling assets, compared to webpack, systemjs, gulp etc at this point in time?
I tried using Brunch, and got that results:
It lacks of functional in comparison with
angular-cli
, but it is much faster. 💨@guiomie we reserve critical for stuff like release bugs, or wholly broken commands. Stuff that usually needs a new release ASAP or no one can do anything.
We recognise that the slowness is crippling and are looking to solutions for it. It’s one of the things we want to address before RC1.
Hi, just wanted to say that I upgraded from beta 18 to 1.0.0 RC1, and the performance increase is spectacular, went from average rebuild of ~3-4 seconds to ~600ms-1000ms. I run “ng build --watch”. Great job on getting this to an acceptable level.
I’ve got an Asus Zenbook 12gb ram, SSD.
Massive improvement for me on Windows 10
beta26: ~12s beta28: ~2s
Thanks!
The problem is each time you save a file webpack will re-create the whole dependency graph of all the vendor and polyfill packages. On top of it, if you are doing this on an ntfs filesystem (windows) it will further increase the rebuild time.
I really wonder why you guys didn’t implement
webpack.DllPlugin
. Last week i created ng-x-cli. Well pretty much it isangular-cli
with all its features i like topped withDllPlugin
.Feel free to check it out whoever still experience bad performance.
P.S: currently it doesnt have a test runner, because i dont write tests
@hansl @hccampos
compilerOptions.isolatedModules
is the one flag that can impact rebuild times in a huge way. I’m using custom gulp tasks for building (on top of CLI project) and if I set"isolatedModules": false
rebuild times for just touching one file are3.39s
,3.33s
,3.29s
. with"isolatedModules": true
I get186ms
,73ms
,82ms
. I’m not familiar with inner workings of webpack, so I’m not sure where/how this would affect other stuff, but I hope it helps (;As mentioned by @filipesilva, the performance was nicely improved with the upgrade to Webpack 2 rc3 (rc4 released today, by the way). However, it is still not as good as it should be, imho. So I decided to do some quick profiling with node-nightly and the chrome dev tools. I haven’t had the time to really dig deep into it, but here are some screenshots of the profile I ran during a 3rd or 4th rebuild, without any file changes.
We can see that the great majority of the time is spent by typescript (and, up to a point, by Webpack) trying to figure out if a file or folder exists in order to properly resolve modules. This makes me wonder if it wouldn’t be possible to have TS and Webpack cache all the files and their locations (relative included) and only re-check them when there is a notification from the filesystem saying that a certain file has actually changed.
Say file A refers to file B and C. If only file A was changed in the filesystem, can check the imports and, if they didn’t change, we know that file B and C exist, we know exactly where they are and ideally we even have their contents in memory somewhere. If, say, only the reference to file B changed, then we can go look only for file B. And so on.
It may actually be the case that the normal watch mode of TSC actually does something similar to what I described above, even though I haven’t had the time to check. It is much faster than via webpack. However, I guess the webpack loader has a harder time because it is just calling TS to compile a certain file or set of files.
Anyone has any other insights? Maybe this could be something to bring up directly with Webpack and Typescript. What do you think?
@asadsahi @cdarken @rosslavery @simonech @gelliott181 thank you so much for all the benchmarks you did! As far as I can tell the CLI is somewhat slower than a barebones webpack run, but it’s usually not that much. So that really makes it seem like it’s a matter of system resources. I’m looking more into making DLLPlugin work on the CLI since that seems to be the only real big performance increase in sight.
@RicardoVaranda the asset optimization listed in the verbose build is actually not related to the assets folder at all. It’s related with stuff like sourcemaps, which is why that time drastically drops if you do
--no-sourcemaps
.@hccampos I asked around and it turns out that
happypack
doesn’t work with loaders that useloaderContext._compiler
. This, unfortunately, is pretty much all typescript loaders.Guys, stop working, go home and rest and happy christmas and happy new year. 🎄 🎅 🎁
Hey all, I’ve been doing some more benchmarks to figure out if we have some gross inefficiencies in our webpack config.
To test that, I setup a very simple webpack app with lazy loading that uses
@ngtools/webpack
as the Typescript plugin. You can find it https://github.com/filipesilva/angular-cli-benchmark-app.webpack-runner.js
is a script that’ll modify the webpack config to have similar defaults asng build/serve
and to let you change it easily.These are the benchmarks I got with that repo: https://gist.github.com/filipesilva/427b0369ccfc7d4d60b77aea90b71141#file-webpack-config-txt
The most significant one is the rebuild time:
I also rank the same app through a similar benchmark using the
ng build/serve
commands: https://gist.github.com/filipesilva/427b0369ccfc7d4d60b77aea90b71141#file-ng-txtAs far as my benchmarks show, there is no significant performance loss using
ng build/serve
versus using a plain webpack config. On the contrary even: rebuilds with the CLI take half the time.To be honest this result surprised me as I expected most of our custom plugins and logic to take a toll on the build time.
So for me this validates the current config generation as performant as a simple webpack config, meaning there shouldn’t be any gross inefficiencies.
The next step is to try and integrate something like DLL Plugin, which should speed rebuilds up.
I had a go at it today, and you can even try it on https://github.com/filipesilva/angular-cli-benchmark-app with
npm start -- --dll
but am running into some problems with the lazy loaded chunks.I also need to find a way to dynamically create the list of modules that will be included in the DLL bundle since users shouldn’t have to list them manually.
I’ll keep you posted on the progress, and if you have suggestions or optimisations I’d love to hear it.
Indeed, huge difference between beta 21 and beta 22. But Is that Ideal?
The point I am trying to make is that developer still waiting mostly for the 3rd party libraries. If a component.ts or component.html file is changed, recompilation should be quick. And DLL is the way to achive that.
All, new stats show ATL (3.0.0-beta.9) taking lead again:
With ts-loader:
With awesome-typescript-loader:
Means, ATL is taking lead in 3.beta9 again.
@mischkl there has been a large amount of activity on ts-loader in the last 2-3 weeks. the ts2.0 situation has changed and I noticed no rxjs issues when using it with fairly large project. There are still the issues I mentioned in my previous comment however.
@clydin 50% is massive difference. Is it worth switching to ts-loader in cli then?
In my case I don’t have to make any change to any path/configuration. Just replaced ATL with ts-loader.
#3011 merged which should help with build/rebuild times. Many thanks to @texel for finding this bug!
Hi! I have implemented the dll option for faster rebuilds. Check my fork to try it: https://github.com/kondi/angular-cli I have more than two times faster rebuild for the default empty project.
Excuse me if this is not the right place to post this, but does webpack use hot module reloading with “ng serve” on Windows? I’ve seen videos on youtube about angular 2 where only the file edited is reloaded instead of rebuilding all files, (in a Mac computer).
@rdwatters you could try this https://github.com/angular/quickstart. It’s a bit faster in my experience. It does not use angular-cli but could be appropiated for testing purposes
Also this could be of interest for anyone reading this:
Working with editors/IDEs supporting “safe write”
Note that many editors support “safe write” feature and have it enabled by default, which makes dev server unable to watch files correctly. “Safe write” means changes are not written directly to original file but to temporary one instead, which is renamed and replaces original file when save operation is completed successfully. This behaviour causes file watcher to lose the track because the original file is removed. In order to prevent this issue, you have to disable “safe write” feature in your editor.
VIM - set :set backupcopy=yes (see documentation) IntelliJ - Settings ▶︎ System Settings ▶︎ Synchronization ▶︎ disable safe write (may differ in various IntelliJ IDEs, but you can still use the search feature)
SOURCE: https://webpack.github.io/docs/webpack-dev-server.html
@intellix https://github.com/angular/angular-cli/pull/2840 should help with
ng test
. It makes code coverage and linting optional. On a test project with 100 component tests, total time went down from 90s to 30s.Same here. Just write to subscribe to the thread. Environment: Intel i7, SSD Disk, Windows 10 => Initial Hello World compilation 15 seconds aprox. Recompilation after minimum changes: 6 seconds what makes it unpractial for agile development.
Using angular quickstart project from github without webpack gives me times of 300 ms for live-reloading. There must to be a way to choose not compiling during development and use bundling and minification only for production in my opinion.
@asadsahi with
beta.17
I registered a 6633ms second rebuild time, is this in line with your experience?+1 also quite slow on linux x64 after I moved my assets from the app folder to the appropriate assets folder, it now optimizes the assets folder every time I make a change to any of the code which seems to be the reason for the added delay.
Ng serve watches for changes and rebuilds only the changed chunks automatically. Killing the process each time forces a full build.
I have hello world project created with ng new HelloWorld
then I run ng build. Takes 62 seconds.
Then I change a line in hello world I run ng build, and it takes 62 seconds again. Is this normal? Is this how you develop?
That explains it. AoT is extremely slow, too slow to be used while developing.
@hanvyj What’s your command line look like?
@hanvyj build or rebuild? Our build times are now at nearly two minutes. Rebuilds are at 3s for no changes up to 30s in some cases. Did some profiling and it is mostly the source maps which are insanely slow. Disable them and builds become way faster…while debugging becomes a nightmare. All in all, you are still quite lucky I think. If things get really bad, there is always the option of ejecting. We have been considering it for a while.
Totally agree with John. Great work! Thanks.
On Mon, Mar 6, 2017 at 1:52 AM, John Livingston notifications@github.com wrote:
– Alban Xhaferllari PHP Developer User Team
I would also be remiss without giving serious kudos to the team. I’ve been updating regularly over the last few months and the last few builds have shown a massive performance increase. Huge thanks all!
Ok, I could fix that (with the fix of beeman described in #4329). But now, rebuild times are back at 15s with beta 28 on windows 7.
There is an open issue appeared with beta 28: https://github.com/angular/angular-cli/issues/4338
@asadsahi the starter you linked uses a different TS loader than we do here, and I think it can’t give complete static analysis information.
I’ll investigate further if the approach used in https://github.com/shlomiassaf/ng-router-loader could be used in the CLI.
@filipesilva DLLPlugin has been implemented in angular2-webpack-starter project recently using this webpack plugin. I like this idea as it is a pluggable way to add dll support. 3rd party packages are listed in that plugin as well. I have this working in one of my project too using same plugin. I have provided in the past stats of normal rebuild vs dll and performance is massive with DLL. And both projects have lazy routes there too.
Do we know what sort of challanges we are having with lazy routes?
@filipesilva we have the same experience in our company. Everyone.
Linux: 4sec Windows: 19sec.
Seems like NTFS (inodes) have serious performance issues with tons of small files
My idea was to use a similar strategy to the one we already use for the vendor chunk to determine DLL packages. Basically all top-level modules requested by the the main (and lazy loaded) chunks that are located in
node_modules
.It might be enough initially to just hardcode the angular packages though.
At the moment I’m still blocked by some weird interactions between the
AoTPlugin
andDLLPlugin
. Builds seem to break as soon as an angular lib is factored out into the DLL bundle.@simonech It’s definitely way too much time, especially for an empty project. I really cannot fathom how could do that. Perhaps an overly aggressive antivirus, or a dying SSD…
You know anyone else with a similar Surface Pro that could try? For a brand new project you should be seeing numbers similar to https://gist.github.com/filipesilva/427b0369ccfc7d4d60b77aea90b71141#file-ng-txt
@khodeN of course ram disk makes the building way more faster. You can put the whole OS into a 1TB ram disk ,then you can fly! 😃
Alright , I am just kidding . So your exp probably proved that this is mostly an IO issue.
beta 22 is much better but still way too slow for my company to be able to consider uaing angular-cli yet.
@JohannesRudolph It’s on npm, just not marked as
latest
yet. You can check the current setup from terminal:To test beta 22 right now, you have to follow https://github.com/angular/angular-cli#updating-angular-cli but change
latest
toexperimental
in the provided commands.I’d like to try the improvements in beta.22, but is it just me or is beta.22 not on npm yet? Are there any plans for pushing it there?
ts-loader
has received a large number of improvements over the last couple weeks and it appears thatawesome-typescript-loader
may be merging functionality back into it.With the latest version of
ts-loader
(1.2.1 as of now) and a quick replacement in the CLI, I was able to see a ~50% improvement on rebuild times (initial build increased ~25%). Be aware that some loader options are named differently (tsconfig
->configFileName
) and for tsconfig paths support the ATL paths plugin is still needed. It also seems to be pulling in the spec files (or at least type checking them); so that will need some investigation (the exclude line is still in the config).NOTE: Production builds are broken with the change. The loader seems to have a conflict with the use of
LoaderOptionsPlugin
.@intellix I have 2 projects, one cli based and a .net non-cli based. In my above comments numbers are from the .net one using latest beta version of webpack 2 (beta 26). Not sure how I can test this with cli based project, but I am asuming something worth trying replacing awesome-typescript-loader with ts-loader to see any difference.
@texel
Can we somehow test this in an existing cli based project?
Is this setting something we can try in a non-cli, webpack 2 based project? I have similar slow rebuilds issue in another project.
@filipesilva Brand new to all-things Angular. I just installed the Angular CLI and am going through the free introductory Angular 2 course on egghead.io. I’ve literally made 1 change to a component file, and the rebuilds are slow (not to be too redundant from everything in this thread):
I know this is still in beta, so please don’t take this negatively, but coming from Ember and React, I’ve never seen builds/reloads this slow. Should I hold off on using CLI for learning NG 2 until the process is a bit faster? I’m looking more for guidance than I am trying to criticize the project. Thanks!
same here , it’s too slow!
https://github.com/angular/angular-cli/pull/2570 moved away from
CopyWebpackPlugin
to a simpler glob copy. This should help with @RicardoVaranda’s issue.