angular-update-guide VS timer-5

update.angular.io *

Hello, i work as a software developer and these days we got a project with the angular in the version 7, one of my tasks is to migrate from 7 to more recent versions, the ideal is the 17. I am trying to follow the step-by-step guide from here:https://update.angular.io/ to go from v7.2 to v8 but i cant even do that. I dont have familiarity with Angular,started to study last week because of this project i mainly work as a backend or with react/next, could you tell what could be the best approach?

Recently, I found myself in charge of upgrading our Angular application from version 12 to 15. In my current role, which I've held for just over a year, most of my focus has been on the backend, and I hadn't even touched the frontend apps until now. I've got to be honest; this upgrade process turned out to be a tougher nut to crack than I initially thought. It's not a knock on the Angular team's Angular Update Guide, though; they did a solid job. The real challenge came from the fact that we had a bunch of custom-made components that didn't quite follow the best practices playbook.

I really recommend the Angular update tool which you can find here: https://update.angular.io

I would like to update Angular from version 5.0 to version 6.1. The instructions at https://update.angular.io/ suggest using ng update @angular/core to update. However this updates directly to version 7 instead of version 6.

Make sure to use https://update.angular.io/ for the upgrade steps and do the upgrade by 1 major version at a time, test if everything works, make a commit and then go for the next version. You may want to go up.

> Every version essentially breaks the previous one.

This is simply not true. It might have been true in the early Angular v2 days, but since v6 or so, updates are relatively trivial.

https://update.angular.io has your back extremely well. The trick is to ensure whatever third party libs you're using have also been updated, otherwise you're application may break.

CLI has improved over the years, enabling smooth migrations between Angular versions. Check out https://update.angular.io/

Just go to https://update.angular.io/ and follow the instructions

I maintain two Angular applications which leverage Angular Material and where dependencies are usually kept up to date.

The first one is my tiny pet project - https://github.com/Klaster1/timer-5 - that I use daily. Updating to MDC components was straightforward and style changes did not cause much trouble.

The second one is a moderately-sized enterprise app I work on as an employee. Every single component update introduces visual regressions the team had to coordinates the fixes for with the UI designer. We split the workload by similar component types, largest pain points being buttons and form controls. Total estimates are in 30-50 hours range, we plan to chip at the task bit by bit until Angular Material 17 arrives, where the legacy component are to be removed.

On a side note, migrating to Ivy-enabled dependencies was on even larger time scale as dependencies had their own breaking changes we spent a ton of effort on, especially Chart.js 2->3 and ag-grid 26->29.

I really enjoy time tracking threads on HN, the domain is straightforward enough for every time there to be an absolutely different set off tools and approaches, without major incumbents dominating the field. The discussions always inspire me to think about my time tracking tool - https://github.com/Klaster1/timer-5 - in a different light and seek inspiration from others.

Several of my projects brought me to similar thoughts. I decided to spend my time on something else unless I use the project in question often and it would really benefit from an occasional refactoring and update. Right now, I've only got a single such project (https://github.com/Klaster1/timer-5), the readme links to several previous iterations. During rewrites, I focused on learning new techniques and tools, but surprisingly, a select few places remained relatively stable throughout the years - either I didn't learn anything new in the area or got it pretty good the first time.

The article resonated with my experience as as software developer.

At my first place, a small outsourcing shop, employees were required to log daily activities so hours per day roughly fit to 8 and 40 per week. From the beginning and unlike most of collectors, I measured my time precisely with https://github.com/Klaster1/timer-5 and soon understood that doing 8 hours per day doesn't happen much and often involves staying late, so instead I simply adjusted the reported numbers to look plausible. In four years, I only received positive feedback on my productivity. What was the management thinking, I have no idea, just like the article says, this was a farce all around.

When I changed the company, the habit to measure productivity stuck. Nowadays, I start working somewhere at 9 and finish at 18, and result is still the same - honest 8 hours of work activity pretty day happen at best once a month, the average week sums to 30-34 hours. Code-related activities never take more than 3-4 hours per day, that includes both coding and reviews. I get the impression that some of my colleagues might spend more time on the job, but low productivity was never a topic of my performance reviews, management seems content with what they get.

Combining a timer wither a calendar sounds like an interesting idea! For almost ten years, I've been using my own app for a similar purpose (tracking work productivity and video games), basically a to do list with timer, plus basic filtration to analyze the data. The app is here: https://github.com/Klaster1/timer-5 .