You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ng update / init broken on an existing project since beta.31 #4584
During the update from beta.30 to beta.31, running ng update or ng init exits after asking me to overwrite README.md.. No matter what option i choose, it just quits straight away without continuing further.
I've created a folder in the past where I add new dummy project each time a new version of Angular-Cli rolls out. Then copy over files to previous one's folder and see changes on git gui.
With ng update if you had your project under source control it was easy to update. Let ng update replace all files then with a git gui compare the changes and take the new ones that you want or leave your unchanged files. Not sure if this was the correct workflow but seemed to work pretty well.
Reacted by Peter Grman, Rey D, spongessuck, Meligy, Tre665 and Vik Sunkavalli
I agree with @splintercode, having to check the changelog to find and apply the minutiae that changed manually every time the CLI updates seems like a step backward.
Unless I am missing something, I think I tried ng init / ng update in a beta.30 CLI project on Windows, I didn't have readme in that project so the file it asked to replace was different (I think it was index.html), then it just ended. I looked at my git and found that the files were changed, and I was able to upgrade my project.
In saying this, I'm agreeing with @splintercode, the way I update my projects is by running ng init, accepting all core files (tslint, tsconfig, editorconfig, test.ts, karma.conf.js, package.json, polyfills, main.ts, etc.) and then going to git to undo the changes I don't want.
Now it seems that the command is misleading, because it brings default files even to app module / component etc. I agree, but I think this has largely increased by calling it ng update. It was more predictable and making more sense to have these effects when it was called ng init.
The reasoning I was given for removing the tool and resorting to changelog instead is that the team expects no changes to these core files (or very minimal) after v 1.0 final - I honestly don't know what to think of this reasoning, as good or bad. It looks like this command is going away a tiny bit earlier than that anyway.
Reacted by Bogac Guven, Cory Rylan , rkrisztian and Vik Sunkavalli
We're getting rid of ng update and init because for the last few betas, we've been entirely backward compatible. The only step needed is to npm install the new version locally (and save your package.json).
What happens if someone is upgrading from an older version like beta.19 or something where there were quite a lot of changes? I recently upgraded from beta.19 to beta.28/30/31 and am glad I did it when ng init/update was still available otherwise it would have been pretty tedious.
@hansl, I don't think you are right: the last few betas had breaking changes too. I always check ng init because it shows changes I need to make but not explicitely pointed out by the change log, and ones that for some reason I would not think of. (Btw the releases on GitHub have empty release notes.) But since ng init mixes @angular/cli changes in the diff with my changes, creating a diff between versions using ng new is a better option anyway, and I will still be using it.
I ran into another issue doing an update, and the only indication of the change was in the update.angular.io site, buried in a paragraph - that the @ViewChild() decorator now takes a required second parameter. This also states that it would automatically update my code.
It did not, and caused many errors, that I had to dig around to figure out that a second parameter was required now - nowhere else, in change notes that I found, had this breaking change....
@jtsom doing ng update should have migrated those automatically, but there are some cases where the update doesn't run (tracked as #14589). We're still trying to figure out why.
There were several in the project and none of them were migrated. Was there a mention in a change log somewhere that that change was happening? None of the "new in Angular 8" articles I read mentioned it... would have saved a bunch of time...
It's in the deprecation guide, linked from the announcement post. It can also be reached from angular.io->releases->deprecation guide. It's a new page though, it wasn't there in version 7.
angular-automatic-lock-bot commented on Sep 9, 2019
Activity
bogacg commentedon Feb 10, 2017
in my case first question was
.editorconfigand exited right after answer given.Windows 10 64 bit
Node 7.5.0
npm 4.1.2
filipesilva commentedon Feb 10, 2017
This is a bug in the current release... but it will be 'solved' as part of #4416, which should be in the next release.
victornoel commentedon Feb 10, 2017
@filipesilva so what is the workaround for everybody that can't call ng update with beta.31?
filipesilva commentedon Feb 10, 2017
@victornoel no workaround per se. Moving forward, all changes that require user project changes should be in https://github.com/angular/angular-cli/blob/master/CHANGELOG.md
Ironically enough, the single change that needed users to update code was left out of the changelog by accident. You can find it here: https://github.com/angular/angular-cli/pull/4587/files
Other than that, to update now you should just need to follow the steps in https://github.com/angular/angular-cli#updating-angular-cli except for
ng update.We'll remove those commands and the instructions soon.
I'll reopen this issue though, a lot of people are running into the problem so it's more visible open.
bogacg commentedon Feb 10, 2017
I've created a folder in the past where I add new dummy project each time a new version of Angular-Cli rolls out. Then copy over files to previous one's folder and see changes on git gui.
jtsom commentedon Feb 10, 2017
Shouldn't those new instructions for the changes to Karma include the --save-dev flag?
To update follow these steps in your project:
npm uninstall karma-remap-istanbul --save-devnpm install karma-coverage-istanbul-reporter --save-devfilipesilva commentedon Feb 10, 2017
Right you are @jtsom!
Zertu commentedon Feb 10, 2017
just now i met the question on windows too
coryrylan commentedon Feb 10, 2017
With ng update if you had your project under source control it was easy to update. Let ng update replace all files then with a git gui compare the changes and take the new ones that you want or leave your unchanged files. Not sure if this was the correct workflow but seemed to work pretty well.
spongessuck commentedon Feb 10, 2017
I agree with @splintercode, having to check the changelog to find and apply the minutiae that changed manually every time the CLI updates seems like a step backward.
goldenbearkin commentedon Feb 11, 2017
@splintercode
The beta 31 version breaks the ng update. I can't even start replacing everything.
Meligy commentedon Feb 11, 2017
Unless I am missing something, I think I tried
ng init/ng updatein a beta.30 CLI project on Windows, I didn't havereadmein that project so the file it asked to replace was different (I think it wasindex.html), then it just ended. I looked at my git and found that the files were changed, and I was able to upgrade my project.In saying this, I'm agreeing with @splintercode, the way I update my projects is by running
ng init, accepting all core files (tslint, tsconfig, editorconfig, test.ts, karma.conf.js, package.json, polyfills, main.ts, etc.) and then going to git to undo the changes I don't want.Now it seems that the command is misleading, because it brings default files even to app module / component etc. I agree, but I think this has largely increased by calling it
ng update. It was more predictable and making more sense to have these effects when it was calledng init.The reasoning I was given for removing the tool and resorting to changelog instead is that the team expects no changes to these core files (or very minimal) after v 1.0 final - I honestly don't know what to think of this reasoning, as good or bad. It looks like this command is going away a tiny bit earlier than that anyway.
1 remaining item
hansl commentedon Feb 13, 2017
We're getting rid of ng update and init because for the last few betas, we've been entirely backward compatible. The only step needed is to npm install the new version locally (and save your package.json).
Closing this.
Blasz commentedon Feb 13, 2017
What happens if someone is upgrading from an older version like beta.19 or something where there were quite a lot of changes? I recently upgraded from beta.19 to beta.28/30/31 and am glad I did it when
ng init/updatewas still available otherwise it would have been pretty tedious.victornoel commentedon Feb 13, 2017
@Blasz that's the problem with using Betas :)
@hansl don't forget also the cli version in angular-cli.json too…
rkrisztian commentedon Feb 13, 2017
@hansl, I don't think you are right: the last few betas had breaking changes too. I always check
ng initbecause it shows changes I need to make but not explicitely pointed out by the change log, and ones that for some reason I would not think of. (Btw the releases on GitHub have empty release notes.) But sinceng initmixes@angular/clichanges in the diff with my changes, creating a diff between versions usingng newis a better option anyway, and I will still be using it.rkrisztian commentedon Feb 13, 2017
In case someone is interested I use the following script to generate the diff (I'm not a fan of global installations):
(Quick and dirty, feel free to improve.)
Edit: Updated to skip npm installation during
ng new(slightly faster).genuinefafa commentedon Feb 14, 2017
@rkrisztian your kinda of script did the trick for me... after a line-by-line comparison... thanks!
shiftgeist commentedon Jun 6, 2019
Is update.angular.io/ still a thing, because it suggests the
ng update?filipesilva commentedon Jun 6, 2019
@shiftgeist yes, that site is up to date.
jtsom commentedon Jun 6, 2019
I ran into another issue doing an update, and the only indication of the change was in the update.angular.io site, buried in a paragraph - that the @ViewChild() decorator now takes a required second parameter. This also states that it would automatically update my code.
It did not, and caused many errors, that I had to dig around to figure out that a second parameter was required now - nowhere else, in change notes that I found, had this breaking change....
filipesilva commentedon Jun 6, 2019
@jtsom doing
ng updateshould have migrated those automatically, but there are some cases where the update doesn't run (tracked as #14589). We're still trying to figure out why.jtsom commentedon Jun 6, 2019
There were several in the project and none of them were migrated. Was there a mention in a change log somewhere that that change was happening? None of the "new in Angular 8" articles I read mentioned it... would have saved a bunch of time...
Thanks.
filipesilva commentedon Jun 6, 2019
It's in the deprecation guide, linked from the announcement post. It can also be reached from angular.io->releases->deprecation guide. It's a new page though, it wasn't there in version 7.
angular-automatic-lock-bot commentedon Sep 9, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.