How to solve technical debt? (angular 5, 2018)

Ionic Framework Ionic Angular
1

Hi everyone!

I currently have an app where the ionic and angular version stayed behind over the last 2 years.
(Started in 2018, check bellow to see the packages used) (I tried to fix it once before but wasn’t easy :sweat_smile: )

There are 3 possible pathways to solve the current technical debt:

  1. Do nothing. Keep the angular/ionic version behind, and carry this debt on. (seems I can still keep the plugins updated, already updated most of them)
  2. Spend 1 maybe 2 weeks trying to upgrade version by version… (already spent yesterday afternoon trying to go from angular 5 to 6 and didn’t finish :scream:)(probably will spend today too!)(routes weren’t a thing before! etc)
  3. Re-start the ionic project as a new one and re-implement all screens (by copying and pasting of course) and fixing what is no longer compatible with the latest. Not sure how long this will take. :thinking_face:

What do you guys think is the best course of action?
P.S. I want/need to solve this technical debt problem because the client wants to make a similar app based on the current one. That means then I will have 2 apps with old dependencies… :grimacing:

package.json:

"scripts": {
	"start": "ionic-app-scripts serve",
	"clean": "ionic-app-scripts clean",
	"build": "ionic-app-scripts build",
	"lint": "ionic-app-scripts lint"
},
"dependencies": {
	"@angular/animations": "5.2.11",
	"@angular/common": "5.2.11",
	"@angular/compiler": "5.2.11",
	"@angular/compiler-cli": "^8.2.13",
	"@angular/core": "5.2.11",
	"@angular/forms": "5.2.11",
	"@angular/http": "5.2.11",
	"@angular/platform-browser": "5.2.11",
	"@angular/platform-browser-dynamic": "5.2.11",
	"@ionic-native/core": "^5.16.0",
	"@ionic-native/in-app-purchase-2": "^5.16.0",
	"@ionic-native/keyboard": "^5.16.0",
	"@ionic-native/market": "^5.16.0",
	"@ionic-native/native-audio": "^5.16.0",
	"@ionic-native/splash-screen": "^5.16.0",
	"@ionic-native/status-bar": "^5.16.0",
	"@ionic-native/vibration": "^5.16.0",
	"@ionic/storage": "^2.2.0",
	"@ngx-translate/core": "^9.1.1",
	"@ngx-translate/http-loader": "^2.0.1",
	"cc.fovea.cordova.purchase": "^8.1.1",
	"cordova-browser": "5.0.4",
	"cordova-ios": "5.0.1",
	"cordova-plugin-device": "^2.0.2",
	"cordova-plugin-ionic-keyboard": "^2.1.3",
	"cordova-plugin-ionic-webview": "^4.0.1",
	"cordova-plugin-market": "^1.2.0",
	"cordova-plugin-nativeaudio": "^3.0.9",
	"cordova-plugin-splashscreen": "^5.0.2",
	"cordova-plugin-vibration": "^3.1.0",
	"cordova-plugin-whitelist": "^1.3.3",
	"cordova-sqlite-storage": "^3.4.0",
	"core-js": "^2.6.5",
	"ionic-angular": "3.9.2",
	"ionicons": "3.0.0",
	"rxjs": "5.5.11",
	"sw-toolbox": "3.6.0",
	"xls-to-json": "^2.1.0",
	"zone.js": "0.8.26"
},
"devDependencies": {
	"@ionic/app-scripts": "^3.2.4",
	"cordova-android": "^9.0.0",
	"typescript": "~4.0.3"
},
2

Hey :blush:

The Migration from v3 to v4 is not nice (because huge framework changes that were needed to make Ionic work with more than only Angular). The Migration Guide from 3 -> 4 is here. As you can see the official way is creating a new app and copy.

Now you are migration from c3 to v5 and also Angular is now on Major 10 (you are using 5^^).

I’m doing a similar migration currently. I would definitively recommend Option 3: Create a new App. I would also go a step more and would say, don’t migrate like the Ionic Migration Guide says, by copying all Services, etc. Better do Page by Page, develop the app nearly new and try to understand what changes in ionic, angular, and all the other packages and whats the best way to do it nowadays. You can still copy much code.

Yeah, that’s my recommendation :smiley:

1 Like
3

Yep, I’m currently trying to migrate version by version (angular 5 to 6 currently) and there are so many errors to fix that I’m leaning towards option 3 more and more… Thanks for the feedback!

1 Like
4

By seeing that guide you reminded me that last time I tried to migrate I had huge problems with shadow dom because I couldn’t style it like in the previous version and my app got destroyed… :grimacing: (would have to rewrite all CSS because I use “ion-content” and others or something like that :sob: cant remember exactly what the problem was)

5

Shadow Dom is something we have to deal with, but it is editable. Ionic provides CSS Variables for some things, but if you know how, you can change everything. But normally that is not what you want, as the Components should look like the native ones does. If you have a complete different styling than native has, you probably should create your own components

1 Like
6

Just to add a few points here…We’ve migrated several apps before we released v4 (which included the breaking changes for styles) and our best practices was

  • first migrate for functionality (make the app function)
  • adopt new styles or rework the old design

If there are styles that are no longer applicable, chances are you shouldn’t have been targeting those internal elements in the first place. The ShadowDOM move allowed up to keep the internals of Ionic’s components isolated and prevent any breaking changes when we need to change how a component is structured (which we’ve already done a few times, and no one noticed). If your older styles no longer work, they either shouldn’t have been there in the first place, or you can look at it as a chance to freshen up your existing app.

3 Likes
7

I have just finished porting an app from V3 to V5, by completely rewriting.

  • I kept both the V3 and V5 projects open in VSCode with ionic serve, porting each service and page so they functionally worked et each stage.
  • I then fixed the styling afterwards.
  • Finally I added new functionality and styling afterwards.

So in principle, I agree with what @mhartington said. However saying that if your older styles no longer work, they shouldn’t have been there in the first place is pretty disingenuous - this is an HTML + CSS framework which purposefully allowed you to tinker with styling as you needed to suit your design, which made it super flexible.

8

The above recommendations are right: the best option is to create a new app and copy your work over.

You should find significant reuse with all of your Angular services, as long as those services don’t rely on older Angular functionality. This is worth doing because a big part of being in the Angular ecosystem is upgrading frequently to stay on the latest versions of tooling/etc.

As for Ionic itself, the biggest challenges will be style changes and routing changes. Ionic Angular 4+ uses Angular Router, while Ionic Angular 3.x had a custom router (since there was no Angular Router when we started Ionic Angular).

But that work will more than pay off since you’ll be on standard Angular APIs and tooling, and you’ll be using our public styling API which will make it much easier to upgrade to future versions of Ionic moving forward.

Good luck!

9

Following @EinfachHans and @mhartington recommendation I’ve gone ahead and created a new project and implemented screen by screen.

I also took the opportunity and wrote an article detailing everything I had to change/fix/do during the process:

P.S. if you find something wrong in the article you can send a PR to fix it: