Ask Minko to add a deprecation notice to the npm package so that when it gets installed it will tell users that: 1. a deprecated package is installed that they might not even be using 2. or if it's being used, maybe they can update to eslint instead if at all possible
Thank you so much for revealing what's behind it 🙏 this has been kinda bothering me too - it just didn't make sense much, but now it does 🙂 versions I am on - 15, 16, 17, 18
4 of 5 projects gone from 1.7.8 to 16. Last one still working through. Hope to have them all to 17+ once that ones done but 12 years of active development is a slow change.
Same. This one stands out because we always talk about trying to be on the latest version of Angular, but the downloads have always reflected something different.
@@BrandonRobertsDev Sure using the Angular cli update schematics. the app is built from different libraries so I had to teach every team of the company on how to deal with that. The application also still partially relies on UpgradeModule for angular.js. We are still running a few third party dependencies using ngcc. I don't know how it plays out with the router since the company uses a router and a UI toolkit I wrote that's partially built on top of Angular CDK (tables, overlay). Basically our feature libraries are mostly built from this toolkit and Angular core/common. We had some issues with a library that was using Material, mostly due to changes in the sass API but was a niche case. For the core/common parts the cli does a really good job on migrating the code and the configuration unit tests included. The Api is mostly consistent from 8-15 so no issues in that regard. We proceeded by ensuring that all libraries met the requirements (es. ModuleWithProviders with generic type set) then we upgraded the projects to ng15 and the first iteration was using ngcc on each library. We later upgraded all the libraries. The ngcc does a great job, it's only annoying if you need to compile them locally and link them since it does require ngcc to run and you can't just serve and watch from changes as easily as normal. I recommend anyone to jump to 15 since most stuff just works if you ignore peer dependencies requirements that may be outdated. From 16 ngcc is no longer a thing so we still need to upgrade some stuff before looking into beyond 15. We're still on rx.js 6 and we have some issues because also if not correctly stated in the breaking changes, rxjs 7 does no more provide rxjs/operators package and for that we may need to refactor many imports in many libraries.. any suggestions on this?
You need a Netflix series - the Sherlock Holmes of weird developer stuff. ;) Did I get this right? Angular 9.0.0 is really the aggregate of all Angular 9-12 because those depend on Codelyzer, so for each install of that, it also counts as a download for Angular 9? Freaky.
Netflix series? Yes, please lol And yes, that's correct. I found so many example projects and repos from v9-12 and all of them when downloaded count every week
@@BrandonRobertsDev I like to update Angular every 3 versions. This way, I can get the latest features without sacrificing project stability. Skipping a version in between gives me time to see if there are any reported bugs or compatibility issues. Of course, if a crucial feature is released in an intermediate version, I'll consider updating for that. Overall, this approach gives me more time between updates, lets me stay within the LTS window, and still get new features without feeling rushed. I'm aiming to migrate to v18 in the coming weeks.
So v9 is the most used because of codelyzer? Did I get it right? If so, I don't understand why this particular dependency makes Angular v9 so popular... I mean, since Angular v12, the angular team added strict mode and it was enabled by default so you would have all these "eslint", "tslint", encouragement of good practices out of the box without using any external package
Yep. It's because even if you've upgraded along the way, Codelyzer is still in your package.json getting downloaded and in turn downloading its own copy of 9.0.0 because of the hard dependency
Just checked my main repo. Codelyzer must have been lost while migrating the code to an Nx monorepo. 😂 But I have some other smaller projects I have to check... Upgrading Angular is easy, that's why I'm using it. But getting rid off old dependencies is hard. I almost never know what all those dev dependencies are really used for...
Yeah, found one in an Angular 14 project. Will remove! (it's on Angular 14, because I didn't had time yet to remove flex-layout. That was a sad day when that got deprecated...)
@@larshanisch it was a sad day when flex-layout got deprecated true, I don't know if it still makes sense to use it today but you can check out ngbracket/ngx-layout, this is the currently maintained version
This has to be the best Angular plot twist out there 😂
Surprising for sure!
Very interesting. Just discovered your video content and I love it! Wanted to say that your work is an inspiration for me
Thanks Alex!
dude! amazing investigation work!
I couldn't let it go lol
Ask Minko to add a deprecation notice to the npm package so that when it gets installed it will tell users that:
1. a deprecated package is installed that they might not even be using
2. or if it's being used, maybe they can update to eslint instead if at all possible
Thank you so much for revealing what's behind it 🙏
this has been kinda bothering me too
- it just didn't make sense much, but now it does 🙂
versions I am on - 15, 16, 17, 18
We can at least explain the numbers better now 👍
4 of 5 projects gone from 1.7.8 to 16. Last one still working through. Hope to have them all to 17+ once that ones done but 12 years of active development is a slow change.
Kudos to you for working through all those migrations!
On Angular 18. That very interesting, that makes me wonder about all the other software out there that have similar issues.
Same. This one stands out because we always talk about trying to be on the latest version of Angular, but the downloads have always reflected something different.
We're on 13, about to update to 14 (and then hopefully all the way to 18).
Good to hear. How often do you update?
@@BrandonRobertsDev Not often enough 😔
just moved an enterprise application from 8.2 to 15 and planned v18 this year.
Nice. How were the upgrades? Did you upgrade one version at a time?
@@BrandonRobertsDev Sure using the Angular cli update schematics. the app is built from different libraries so I had to teach every team of the company on how to deal with that. The application also still partially relies on UpgradeModule for angular.js. We are still running a few third party dependencies using ngcc. I don't know how it plays out with the router since the company uses a router and a UI toolkit I wrote that's partially built on top of Angular CDK (tables, overlay). Basically our feature libraries are mostly built from this toolkit and Angular core/common. We had some issues with a library that was using Material, mostly due to changes in the sass API but was a niche case. For the core/common parts the cli does a really good job on migrating the code and the configuration unit tests included. The Api is mostly consistent from 8-15 so no issues in that regard. We proceeded by ensuring that all libraries met the requirements (es. ModuleWithProviders with generic type set) then we upgraded the projects to ng15 and the first iteration was using ngcc on each library. We later upgraded all the libraries. The ngcc does a great job, it's only annoying if you need to compile them locally and link them since it does require ngcc to run and you can't just serve and watch from changes as easily as normal. I recommend anyone to jump to 15 since most stuff just works if you ignore peer dependencies requirements that may be outdated. From 16 ngcc is no longer a thing so we still need to upgrade some stuff before looking into beyond 15. We're still on rx.js 6 and we have some issues because also if not correctly stated in the breaking changes, rxjs 7 does no more provide rxjs/operators package and for that we may need to refactor many imports in many libraries.. any suggestions on this?
That sounds like a nightmare to me lol
RxJS still has rxjs/operators in 7.x for backward compatibility. We've stuck to using those in libraries because not everyone is using RxJS 7.,
Angular 9. So hot right now.
And will be 😭
no please dont
🤣
you are not cool if you are not using v9 🤣🤣🤣 jk of course
Usually who use that old school packages in project don't watch this type of videos. That's a problem.
Good point. Maybe this will start to spread the word
You need a Netflix series - the Sherlock Holmes of weird developer stuff. ;) Did I get this right? Angular 9.0.0 is really the aggregate of all Angular 9-12 because those depend on Codelyzer, so for each install of that, it also counts as a download for Angular 9? Freaky.
Netflix series? Yes, please lol
And yes, that's correct. I found so many example projects and repos from v9-12 and all of them when downloaded count every week
those would be some cool series :) I would watch
I think its also cause 3rd party libs struggled to update to ivy or did update to ivy but also introduced huge breaking changes.
Definitely, the 3rd party lib ecosystem needs better tools to handle upgrades also
I'm using version 16.2.12, I update the projects every 3 versions. For example, from 13 to 16
Interesting! Why every 3 versions? That way you're still in the LTS support window?
@@BrandonRobertsDev I like to update Angular every 3 versions. This way, I can get the latest features without sacrificing project stability. Skipping a version in between gives me time to see if there are any reported bugs or compatibility issues. Of course, if a crucial feature is released in an intermediate version, I'll consider updating for that. Overall, this approach gives me more time between updates, lets me stay within the LTS window, and still get new features without feeling rushed. I'm aiming to migrate to v18 in the coming weeks.
Thanks for the insight!
Still on 1.8
👀
No plans to upgrade or migrate?
@@BrandonRobertsDev Yes, ive been saying it for years. new projects are done in Angular 15, these will beupgraded soon for.
Cool investigation)
Thanks. I'm glad to finally get this out of my brain :)
So v9 is the most used because of codelyzer? Did I get it right? If so, I don't understand why this particular dependency makes Angular v9 so popular... I mean, since Angular v12, the angular team added strict mode and it was enabled by default so you would have all these "eslint", "tslint", encouragement of good practices out of the box without using any external package
Yep. It's because even if you've upgraded along the way, Codelyzer is still in your package.json getting downloaded and in turn downloading its own copy of 9.0.0 because of the hard dependency
eslint/tslint were added later, and they are third-party packages also
Just checked my main repo. Codelyzer must have been lost while migrating the code to an Nx monorepo. 😂 But I have some other smaller projects I have to check...
Upgrading Angular is easy, that's why I'm using it. But getting rid off old dependencies is hard. I almost never know what all those dev dependencies are really used for...
Yeah, found one in an Angular 14 project. Will remove!
(it's on Angular 14, because I didn't had time yet to remove flex-layout. That was a sad day when that got deprecated...)
😮
@@larshanisch it was a sad day when flex-layout got deprecated true, I don't know if it still makes sense to use it today but you can check out ngbracket/ngx-layout, this is the currently maintained version
Lol! That's hilarious. Subscribed
🤝
9.0 === Goat ?
Yes, of course 😂
So Version 9 will live forever in seperate timeline 😅
TENET 😂
Wow Interesting 😂
😅
So, mgechev is the culprit? lol
lol, I'm sure there's a reason it was pinned, but its been skewing the numbers for yearsss 😂
@@BrandonRobertsDev I guess he forgot about it? Did you ask him? :D
I am still coding in angularJS, pray for me, legacy code sucks.
Hopefully at least your on AngularJS with the .component function? 🙏
@@BrandonRobertsDev yes thank god! I am migrating AngularJS to Angular 17, step by step, pain in the a$$
Me too! ngUpgrade does work though.
We need to delete less than angular version 10 😅 just a thought
lol that would be something
that would be a lot of work, but if you start I will be supporting you
and sending tons of encouragement along the way 😃😇