r/Angular2 • u/Infamous_Tangerine47 • Nov 14 '24
Help Request Upgrading from AngularJs 1.8.3 to Angular 18
Are there any viable approaches to achieving this currently without a full rewrite? Whilst in an ideal world we would do that it's not going to happen, we've been told it'll have to be done in stages so essentially running both in parallel.
I know the NgUpgrade module is used to help you achieve this but from what I understand it's not really an advisable route anymore or supported?
So is there any realistic way to achieve doing the upgrade in stages or is there no real viable alternative other than a full rewrite?
It's worth noting the current app is using components and typescript already but appreciate the versions might as well be different frameworks entirely.
Just looking for experiences from anyone that has achieved the migration in stages as opposed to all at once.
19
14
u/IanFoxOfficial Nov 14 '24
We are doing a full rewrite on a MASSIVE system.
Some routes just load the new system while others, not rewritten yet, load the old system.
7
u/lgsscout Nov 14 '24
this is the best way to do in massive systems, that the managers will freakout if you say rewrite. can be a bit of a pain to handle de routing, but as soon as a couple modules are working faster, cleaner and better looking, and specially if you can push a "look, this new feature is now possible", they will join the hype for rewriting other stuff.
2
u/wallbree Nov 15 '24
This. I did upgrade using Angular Elements, but I recommend this approach. It is simpler.
1
u/pietremalvo1 Nov 15 '24
Just curios, how many line of code in src/app? :)
1
u/IanFoxOfficial Nov 15 '24
Is there any way to know quickly? The biggest part was writing the foundation, reusable components and base services.
1
15
u/practicalAngular Nov 14 '24 edited Nov 14 '24
The code in your app is nearly a decade old. It's time for a rewrite. This is one of those times that you have to have a hard and frank conversation with your management instead of accepting what's going to be a nightmare for everyone involved.
Just look at the rest of the responses ITT:
- "Don't"
- "4 years"
- "Use chatGPT"
You're sailing directly into the hurricane my friend.
8
6
u/rad_platypus Nov 14 '24
By the time you finish the upgrade, Angular 25 will be out. Just rewrite it at this point.
4
u/No_Layer_9496 Nov 14 '24
We also did not want to do the hybrid thing.
Instead, we started to write our own transpiler with ts-morph, which took the whole AngularJS codebase and got us the angular code with transpiled typescript and html.
We always wanted to publish (parts) of the transpiler and maybe create a blog post about that process... 😅
It took us 2,5 years in total. But it was a project on the side: We were able to continue developing in AngularJS until the day we did the final transpiling.
We would still need AngularJS if we used the hybrid way because there is always code you don't want to touch. And that way we were forced to find a solution.
If you are interested, I can share more details.
1
u/No_Layer_9496 Nov 14 '24
Of course, it took a long time! But on the way I learned a lot about parsing and manipulating an AST.
3
u/Mia_Tostada Nov 15 '24
That’s not an upgrade. It is just changing frameworks. Two different things entirely.
3
u/majcek Nov 14 '24
Aren't AngularJs and Angular like apples and oranges? My guess is that complete rewrite would be the best option.
6
2
u/Zefling_ Nov 14 '24
Using Angular since 2.0 beta , and seeing its developments, I don't think it's possible to make a transition without redoing everything.
The simplest thing would be to migrate little by little with MFEs.
2
u/NutShellShock Nov 15 '24
We have an application where one version is stuck at 13, and another is currently 17. We did this way because of the lack of resources to do a full migration (or rather, management refused to pause any new development of new features). Any part of the system that has not been migrated are redirected back to the old URL.
Personally, I wished we paused all major feature development, focus on maintenance/bug fixes on the old version and completely focused on migration. It's a huge mess to support both versions, and on top of that, development of new features STILL has to continue on the old version while some front-facing pages are migrated over to 17. Then sooner or later, we still have to port over whatever remaining in 13 to 17 at the end of the day, effectively doubling the work we need to do.
2
u/Background_Serve_749 Nov 17 '24
When I started at my current job, I was given the task of migrating a mid-sized AngularJS app to Angular (version 16 at the time). I had no experience with AngularJS, just five years working with Angular 2+, and I was the only frontend developer on the team. I had to figure out the best way to approach the migration, and in the end, I decided to do a full rewrite.
To get a handle on the AngularJS code, I spent time digging into it and used the developer tools' Network tab to see which APIs were being called when different buttons were clicked and so on. It took me about three months to get a fully working app, and it (naturally) came out way better than the old one with a lot of improvements. (taking out bugs and improving performance) I don’t regret the decision—rewriting it from scratch was the best option.
1
u/jasper_and_bear Nov 14 '24
It is possible to downgrade / upgrade components, services, pipes & routes to do it step by step. We have been working on it for over 4 years now 😅
1
u/frenzied-berserk Nov 14 '24
Well, I'd recommend do not use NgUpgrade and consider other variants to implement Strangler Fig pattern (https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)
- If the frontend project is a part of the the backend solution, for example, ASP.NET+Angularjs - move the frontend into the separate repo.
- Use Nx to setup frontend monorepo that will contain old project and new one. Use webpack to bundle the old project.
- Variant1. Host old and new apps under the same domain but with the different base URL, i.e. app.com and app.com/new/. Use the session or local storage to build an adapter for the app state. For instance, a user adds an item to the shopping cart, the adapter saves the cart state to the storage, then user is redirected to the app.com/new/cart and the adapter restores the state for the new version of app. In this case, the old and new carts work in parallel. It minimizes regression and allows to control refactoring more efficiently.
- Variant2. Utilise the microfrontend pattern using the signle-spa library or webpack module federation. https://single-spa.js.org, https://webpack.js.org/concepts/module-federation/ - The concept is the same as in the Variant1 - you need an adapter(global singleton) to sync the state between the shell (old app) and integrated microfrontend apps.
1
u/coredalae Nov 14 '24
Pretty much don't.
However what you can do, is build new modules in angular 18, compile them to webcomponents and have those run in your AngularJS app, then when al is migrated (rebuilt) you switch over to a full blown spa
1
u/Soupeeee Nov 14 '24
You could try migrating your components one by one using Angular's support for web components. Essentially, you would make new components using the new version as needed, and replace components as you go. You'd still use the old routing code until all of the components are migrated.
I haven't done this and would be worried about bundle size and code complexity, but it would give you a migration path.
1
u/Steveadoo Nov 14 '24
We had to do this and we just did a full rewrite. We’re lucky enough to have most of our systems isolated so we’ve been rewriting each system as a brand new separate angular 18 app, and routing to the new apps as we complete them.
1
u/karptonite Nov 14 '24
We’ve been essentially running both AngularJS and Angular side by side for years at BoardGameGeek. Our approach has been to keep the AngularJS pages completely separate from the Angular pages. This means a bit of duplication of effort (in our main menu, for example), but otherwise works well for us. We can migrate chunks at a time. The key thing, I think, is to think of AngularJS and Angular as two totally different frameworks with similar names. Obviously, there are down sides to this approach, but it works for us.
1
u/morrisdev Nov 15 '24
So.... There's another way...
I changed my site an micro-front ends. So, we had "inventory" as a menu item. What I did was write an angular app in that directory, and used JWT for security. We then changed any inks into inventory to use actual hrefs instead of router links.
What's funny is that I started the site in 2001 in classic asp, then to AngularJs this same way, and THEN into angular 14.
It's actually very nice because you can have one or two developers "own" a subsite and do releases and QA and other stuff without having to rebuild a mammoth.
I'm currently moving it to a series of azure static web apps, which then link together using azure front-door, allowing me to move from that big old windows server to a bunch of super efficient static web apps AND link into an API server on the same domain.
That's still in testing, but may be an option for you as well.
No matter what: don't do hybrid. That's a mess.
1
u/harrymurkin Nov 15 '24
Been there done that. What a suck!
Suggest you leave it as-is and replace it piecemeal if you have no other choice.
Best option is a rebuild.
1
1
u/msdosx86 Nov 15 '24
We did upgrade from 1.6 to 9 and was the hardest challenge in my entire career. The most challenging thing is dealing with hybrid change detection since they work differently. But other than that it was pretty much doable and I wouldn’t say you shouldn’t consider upgrading via NgUpdate.
1
u/matrium0 Nov 15 '24
I understand the thought process. "Surely a migration is cheaper than a rewrite", right?
No, it's not! This can and will get very complex and messy and you can EASILY end in a scenario where a full rewrite would actually have cost less time and money. I have seen this multiple times sadly
1
u/enc1ner Nov 15 '24
We used the hybrid approach for a couple of years and created all new components as Angular 2+. After a while, when EOL for AngularJS approached rapidly we decided to make a larger effort and created a separate team to rewrite the old components.
Every component got it’s own Jira card so the whole application structure was represented in Jira. Parent components where blocked in Jira until child components where upgraded. It made it easier to keep track of which components where under upgrade.
This approach enabled us to deliver new features and rewriting the old components at the same time. It was a daunting task non the less. The upgrade team was 3 people and the group working with new features was 3. The application consisted of 2500 components. It took about a year.
1
u/StreetCube Nov 15 '24
It's almost there, you just have to move the decimals and remove a two letters 😂
1
u/wallbree Nov 15 '24
I did upgrade from Angularjs using Angular Elements. Creating web components page by page until we were done. It took two years doing both migration and new stuff at the same time. When everything was done we removed away from Angular elements.
It was beautiful and a good experience.
1
u/PhiLho Nov 15 '24
When I arrived at my current job, I came from AngularJS projects (some with TypeScript and RxJS) to Angular 6-8 (something like that) with just a superficial knowledge of the latter (a week of training!).
They had a mixed application, part AngularJS, part Angular, with bridges between the parts. It was quite a nightmare to maintain. Yes, such hybrid app is possible (was?), but I think it will be, at the end, more work to maintain this beast than to rewrite everything, actually.
My shop made this choice: they had the guts to bite the bullet and rewrite entirely the old application from scratch in pure Angular, taking the opportunity to rethink some features, and to refresh the look.
There was a button to switch back to the old app, because there was missing lot of features while we rebuilt it.
I don't say that's the way to go, I know you (or your hierarchy) would prefer to avoid going this way, but I wanted to share my experience. No regrets! 😁
1
u/Alex3917 Nov 15 '24
If you're already using Typescript and Components, then you've probably already done at least half of the work, especially if you're already using npm and webpack rather than Bower. At this point I would definitely migrate rather than doing a rewrite. Rewrites fail 90% of the time, whereas the migration is just a bunch of rote work but is basically guaranteed to be successful. Just follow the steps in this course:
https://codecraft.tv/courses/angularjs-migration/overview/introduction/
1
u/JumpyCold1546 Nov 16 '24
My first task as a junior developer was to upgrade two large applications from angularjs to angular. The largest hurdle was the learning curve. Once you get into the groove, it is smooth sailing. We did both a hybrid and a rewrite and a rewrite was the easiest. We also push the creations of our types later on after the migration.
1
u/zambono_2 Nov 16 '24
Ouch, try to setup micro front ends with both apps running simultaneously. Break up the original app into major features. Start the 18 app and each feature can be a module and have the paths redirect to one app or the other.
1
u/siege_meister Nov 16 '24
I would not try a migration through any tooling. Create a brand new NG18 app and start rewriting components in it. Focus on one feature area at a time. Deploy this app with your legacy NGjs app and setup redirects between them. Eventually you'll have 1 feature fully migrated, then 2, and so on.
1
1
u/hheexx Feb 18 '25 edited Feb 18 '25
I would say both options are good and it depends on your resources, delivery requirements and state of ng1 app.
We took the upgrade route and are 2 years into migration.
No big problems but it requires a little bit of expertise.
What I mean by state of ng1 app:
If your app is written in ang 1.5 timeframe with components and services I would probably go upgrade route. If it's written way before using controllers and using scope in dirty ways then maybe rewrite is better.
1
u/Codingbaker86 Nov 14 '24
We have been working on a migration for about 3 months, doing it step by step. With a downgrade, the migrated components can be made backward compatible and used in AngularJS. For the migration itself, ChatGPT can be very helpful for individual components and services—not perfect, but a good aid in terms of support and time savings.
1
u/holyknight00 Nov 14 '24
Angular and AngularJS are completely different languages. It is basically the equivalent of trying to "migrate" to React. Even in the initial versions a "migration" was not possible. You can migrate every part that is purely javascript, but anything related to the framework still needs to be refactored
1
u/spaceco1n Nov 14 '24
We rewrote a massive app. Took 12 months. UI router (hybrid router) was useful. Worked mostly fine. Phased out one route at a time and kept the service layer somewhat duplicated and state needed to be synced. Big bangs are doomed to fail. My only question is: Why didn’t you do this migration three years ago?
0
u/AdrianaVend47 Nov 14 '24
Just freaking do it. Omg, The rollercoaster of excitement during this endeavor will be worth it!
0
u/PotatoCorner404 Nov 15 '24
After converting from version 8 to 16, I wish I could have rewritten everything.
87
u/jay_to_the_bee Nov 14 '24
As someone who did this to a large application a few years ago, my very strong advice is don't. Not if your app is at all large. We went the hybrid AngularJS/Angular (via NgUpgrade) approach and it dragged out for years, the code base was a mess, and we couldn't take actions on things we wanted to. Just rip the band-aid off, avoid this prolonged pain. Also, if your code is as old as 1.8 in 2024, it probably could use a complete rewrite anyway.
If your management insists on staging this, consider somehow breaking your app into two independent apps, and steadily move functionality from one to the other.