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
Versions. Please run ng --version. If there's nothing outputted, please
angular-cli: 1.0.0-beta.1
node: 5.7.0
os: darwin x64
It would be really usefull to add cli commands for:
rm = removing a component
mv = moving / renaming a component
Unless I am missing it, I don't see that this exists and it would be really useful during refactoring to avoid all the manual updates that come with this process.
Here's a bit of further feedback. The current way that CLI creates new components and other pieces has the merit of following the nascent style guide. So perhaps this feedback is really for the style guide. It certainly creates quite a lot of duplication and naming. For everything that we add using this tooling, we get N copies of its name across multiple directories and files, with two different variations of the name. When the time comes to rename (which happens quite often in real applications), this adds lots of friction. I suppose there is nothing to be done about it; the decision has already been made that the official style will be to use two different variations of every name (or more) and to spray them across many files. But there certainly is an opportunity for the CLI to ease the trouble that this decision creates.
Reacted by Francisco Roca, GunnarGitHub, Mohamed Hussein, Yaroslav Admin, Максим Иванов, Lukas Dörig, Ralph Theart, Eternal21, Guruprasad Bhat, Trevor Rydalch and 5 more
@kylecordes overall refactoring of typescript projects is quite well supported across different IDEs via typescript services. Refactoring a name should operate correctly across the project, and disregarding other variables with the same name.
I'm also not too clear what you mean by "N copies of its name" and "two different variations of every name", but you are right that those are style guide decisions and not CLI decisions - the CLI merely implements the style guide to the best of it's ability.
Renaming a component would be very useful to have CLI feature. I was expecting this feature to be there and saw the CLI help and was disappointed because it wasn't.
I have to rename atleast 5-6 files (*.component.ts, *.scss, *spec.ts, *.service.ts, etc) and then update those files where the component was imported or used. (e.g. app.routes.ts and other files). A quick CLI command for this would be a big timesaver.
Reacted by Ryan Hartzfeld, Mike Payne, Karan Sharma, Mike Pearson, curt, Nipun Madan, amplexor-kv, Jesse, Giorgio Fellipe, Alec Fullmer and 102 more
A ng destroy would be a good opposite of ng generate as the readme introduces generate like ng generate component my-new-component which creates MyNewComponentComponent.
Reacted by mairan, Giorgio Riccardi, Nick R, Julio Isaías, SAKLI Bacem, Hannes Stefani, David Dias, Alex Rozhnov, Patrick Williams, fritz and 40 more
Reacted by Costas Zeimpekis, Aktarul Islam, gitlines, Milan, Nathan Goodman, TRAN Ngoc Thach, Adam Barczewski, GershonA, Ralph Theart, mirek001 and 7 more
Just ran into this where I had created a component, imported packages that had the same named components and I was left having to tediously update all the files connected to my previously generated component. A rename would be a godsend.
Reacted by arghen, Ralph Theart, presiana, spinspume and SuryaKavutarapu
@MA-Agent I see you mentionned considering to write a script yourself. Do you have any news on that ? I am pretty sure a few people here might be interested 👀
It's pointless really am just gonna right that script myself since they're not considering this as a must need command...
It seems easy but it has a big scope. When you remove a component then you will have to visit all files to check if it's component use anywhere else or not. While we add a component we mention module same we will have to do while removing.
And what will you do if the component is moved in the directory of another module. Maybe you have modules in nested directories, or maybe you use some constants in order to avoid copy/paste between the declarations and exports of the @NgModule(). I think that this is way out of scope.
What will you do with page components? What about dialog that are used at runtime, that used to be in entryComponents, like dialogs. And then, what do you do with CSS classes and related things?
Here's an old "recursive rename" script of mine, it only updates content in the directory that you give it, and that directory needs to contain a single component (and with extra related things like component specific services)
My feeling is that this story is very much out of the scope for the Angular CLI.
Each project has it's own unique structure and if you really want to. You can implement your own schematic or maybe a 3rd party library could implement some generic schematics.
But I think that it will be to much work for the Angular CLI team to maintain. There will be way to many issues reported regarding this feature. So: 👎
We discussed this issue within the CLI team today and had a few thoughts. This issue seems to cover multiple use cases, so to address them individually:
Delete component
There is not much the CLI can do in order to more intelligently delete an Angular component. We can't intelligently remove all references to a component, so it's up to the user to refactor their app such that a component isn't used. That is 90% of the meaningful effort around deleting a component, so manually deleting multiple files isn't consuming a critical amount of time.
A trivially simple command to do this would be:
rm foo.component.*# OR
rm foo.service.*
The Angular CLI can't really be much more intelligent than this, so implementing it doesn't provide much value to users.
Move component
(In this context, I'm defining "moving" a component as moving it into a different directory with the same name, as opposed to "renaming" a component which stays in the same directory.)
Moving a component is quite tricky due to the way NgModules work. Many users would expect that moving a component from foo/ to bar/ would also change it to be included in @NgModule class Bar { } instead of @NgModule class Foo { } (depending on file structure). Currently the CLI doesn't have knowledge of NgModule structure like this. Even after moving a component into a different NgModule, it may break other modules which include Foo but do not include Bar. Whether it is reasonable to start depending on Bar requires application context which the CLI does not have.
Alternatively, the CLI could ignore NgModule and just move the component, but again that can be done with a trivially simple script.
mv foo.component.* bar/
# OR
mv foo.service.* bar/
IDEs can be a bit smarter about this and update imports to use the new path, but there's not much the CLI itself can do that would be better than that.
Rename component
(In this context, I'm defining "renaming" a component as staying in the same directory, as opposed to "moving" it into a different directory.)
If we only rename a component and keep it in the same directory, then that dodges a lot of the NgModule questions. There are some improvements which could be made here.
Rename all the files associated with a component at once, in a single operation.
Rename templateUrl and styleUrls: These are references to local files which would be renamed as part of the operation. It makes sense to rename these values as well. IDEs probably would not know to change this (some heuristics might cover this case though).
Rename internal symbols: If you have a foo.component.ts with a export class FooComponent { }, and then renamed the file to bar.component.ts, it may be reasonable to also rename the class to BarComponent (this is probably more debatable, TBD if that is what users expect/want).
All of these are more of an IDE feature than a CLI feature. After some discussion among the CLI team, we feel that these features make more sense in the Angular language service than they do in the CLI itself. I believe there are often hooks to handle file renaming, where these features could be directly implemented. Through the language service, it could also provide these same features when moving across directories (ignoring the NgModule challenge). This would probably be a much cleaner user experience and would be much more usable than going through the CLI.
I filed angular/angular#65524 for the language service to make the changes there. However, we don't think it makes sense to include this kind of feature in the CLI itself. All these use cases are either handled just as well by existing well-known and supported tools, or would be better served in the language service than in the CLI.
I agree with your opinions, this is really hard to let Angular CLI do this. The IDE should be more intelligent and can help refactor instead of Angular CLI. Thank for answer
It will be nice-to-have rm remove command as some time we just create angular components and need to rename them. As this rename command is not there, deleting the created angular component, directive, etc and again running the command to create the component is a pain.
Activity
sWW26 commentedon May 24, 2016
ember-cli has
ember destroyfor removing items.And there's an
afterUninstallhook that can be used to remove barrel registration.filipesilva commentedon May 25, 2016
ember-cliindeed does have those commands, but they currently are not working correctly with the blueprints.kylecordes commentedon Jun 6, 2016
Here's a bit of further feedback. The current way that CLI creates new components and other pieces has the merit of following the nascent style guide. So perhaps this feedback is really for the style guide. It certainly creates quite a lot of duplication and naming. For everything that we add using this tooling, we get N copies of its name across multiple directories and files, with two different variations of the name. When the time comes to rename (which happens quite often in real applications), this adds lots of friction. I suppose there is nothing to be done about it; the decision has already been made that the official style will be to use two different variations of every name (or more) and to spray them across many files. But there certainly is an opportunity for the CLI to ease the trouble that this decision creates.
filipesilva commentedon Jun 7, 2016
Somewhat related issue: #357
@kylecordes overall refactoring of typescript projects is quite well supported across different IDEs via typescript services. Refactoring a name should operate correctly across the project, and disregarding other variables with the same name.
I'm also not too clear what you mean by "N copies of its name" and "two different variations of every name", but you are right that those are style guide decisions and not CLI decisions - the CLI merely implements the style guide to the best of it's ability.
pramttl commentedon Jul 5, 2016
Renaming a component would be very useful to have CLI feature. I was expecting this feature to be there and saw the CLI help and was disappointed because it wasn't.
I have to rename atleast 5-6 files (*.component.ts, *.scss, *spec.ts, *.service.ts, etc) and then update those files where the component was imported or used. (e.g. app.routes.ts and other files). A quick CLI command for this would be a big timesaver.
heysushil commentedon Dec 7, 2016
I didn't get the solution for - how to remove component by angular-cli . I was tried my examples but still get nothing ! rm and mv didn't worked ?
leehericks commentedon Dec 12, 2016
A
ng destroywould be a good opposite ofng generateas the readme introduces generate likeng generate component my-new-componentwhich creates MyNewComponentComponent.solanoepalacio commentedon Feb 13, 2017
I as well believe a ng destroy would be quite usefull
Gastalver commentedon Mar 13, 2017
+1 to ng destroy or ng remove
antipalindrome commentedon Mar 17, 2017
Just ran into this where I had created a component, imported packages that had the same named components and I was left having to tediously update all the files connected to my previously generated component. A rename would be a godsend.
asifbherani commentedon Apr 2, 2017
How do we distroy component as when I try to use ng d c or ng r c it throws the following error: The destroy command is not supported by Angular CLI.
88 remaining items
HunteRoi commentedon Jan 8, 2020
@MA-Agent I see you mentionned considering to write a script yourself. Do you have any news on that ? I am pretty sure a few people here might be interested 👀
SaboSuke commentedon Jan 16, 2020
It's pointless really am just gonna right that script myself since they're not considering this as a must need command...
xEt3 commentedon May 11, 2020
+1
sacgrover commentedon Jun 2, 2020
It seems easy but it has a big scope. When you remove a component then you will have to visit all files to check if it's component use anywhere else or not. While we add a component we mention module same we will have to do while removing.
SchnWalter commentedon Jun 2, 2020
And what will you do if the component is moved in the directory of another module. Maybe you have modules in nested directories, or maybe you use some constants in order to avoid copy/paste between the declarations and exports of the
@NgModule(). I think that this is way out of scope.What will you do with page components? What about dialog that are used at runtime, that used to be in entryComponents, like dialogs. And then, what do you do with CSS classes and related things?
Here's an old "recursive rename" script of mine, it only updates content in the directory that you give it, and that directory needs to contain a single component (and with extra related things like component specific services)
My feeling is that this story is very much out of the scope for the Angular CLI.
Each project has it's own unique structure and if you really want to. You can implement your own schematic or maybe a 3rd party library could implement some generic schematics.
But I think that it will be to much work for the Angular CLI team to maintain. There will be way to many issues reported regarding this feature. So: 👎
dgp1130 commentedon Jun 11, 2020
We discussed this issue within the CLI team today and had a few thoughts. This issue seems to cover multiple use cases, so to address them individually:
Delete component
There is not much the CLI can do in order to more intelligently delete an Angular component. We can't intelligently remove all references to a component, so it's up to the user to refactor their app such that a component isn't used. That is 90% of the meaningful effort around deleting a component, so manually deleting multiple files isn't consuming a critical amount of time.
A trivially simple command to do this would be:
The Angular CLI can't really be much more intelligent than this, so implementing it doesn't provide much value to users.
Move component
(In this context, I'm defining "moving" a component as moving it into a different directory with the same name, as opposed to "renaming" a component which stays in the same directory.)
Moving a component is quite tricky due to the way
NgModules work. Many users would expect that moving a component fromfoo/tobar/would also change it to be included in@NgModule class Bar { }instead of@NgModule class Foo { }(depending on file structure). Currently the CLI doesn't have knowledge ofNgModulestructure like this. Even after moving a component into a differentNgModule, it may break other modules which includeFoobut do not includeBar. Whether it is reasonable to start depending onBarrequires application context which the CLI does not have.Alternatively, the CLI could ignore
NgModuleand just move the component, but again that can be done with a trivially simple script.IDEs can be a bit smarter about this and update imports to use the new path, but there's not much the CLI itself can do that would be better than that.
Rename component
(In this context, I'm defining "renaming" a component as staying in the same directory, as opposed to "moving" it into a different directory.)
If we only rename a component and keep it in the same directory, then that dodges a lot of the
NgModulequestions. There are some improvements which could be made here.templateUrlandstyleUrls: These are references to local files which would be renamed as part of the operation. It makes sense to rename these values as well. IDEs probably would not know to change this (some heuristics might cover this case though).foo.component.tswith aexport class FooComponent { }, and then renamed the file tobar.component.ts, it may be reasonable to also rename the class toBarComponent(this is probably more debatable, TBD if that is what users expect/want).All of these are more of an IDE feature than a CLI feature. After some discussion among the CLI team, we feel that these features make more sense in the Angular language service than they do in the CLI itself. I believe there are often hooks to handle file renaming, where these features could be directly implemented. Through the language service, it could also provide these same features when moving across directories (ignoring the
NgModulechallenge). This would probably be a much cleaner user experience and would be much more usable than going through the CLI.I filed angular/angular#65524 for the language service to make the changes there. However, we don't think it makes sense to include this kind of feature in the CLI itself. All these use cases are either handled just as well by existing well-known and supported tools, or would be better served in the language service than in the CLI.
hiepxanh commentedon Jun 12, 2020
I agree with your opinions, this is really hard to let Angular CLI do this. The IDE should be more intelligent and can help refactor instead of Angular CLI. Thank for answer
Sti2nd commentedon Jun 12, 2020
Hope there will be a language server for Angular left to implement this, seems like they lack manpower? angular/vscode-ng-language-service#335
semslam commentedon Jun 15, 2020
It will be nice-to-have rm remove command as some time we just create angular components and need to rename them. As this rename command is not there, deleting the created angular component, directive, etc and again running the command to create the component is a pain.
angular-automatic-lock-bot commentedon Jul 19, 2020
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.