Get rid of "^" dependency HELL

[montella1507]

Hello,

can you please stop use that JavaScript NPM hell of Carrot versioning?

I think the users of CLI / Angular spent 30% of their time with fixing new BUGS and breaking changes in new "submodules" - their uncompatibility.. You can USE "not latest" CLI and what worked DAY 1 doesnt work in DAY 2 after NPM REINSTALL, because of changes @webpack/devtools, or another HIDDEN dependency in a dependent sub-module of another dependent sub-module,...

I really didnt get that purpose of not-concrete versioning of submodules in JavaScript world,.. My experience is that 99% of JS developers have not good manner of semantic versioning so there is a breaking change and tons of bugs in every new Patch/minor version...

I think it should be changed everywhere to CONCRETE version, why to have NOT-concrete version in dependencies? It only leads to changed behavior EVERY day,.. I think it is common way to use some kind of Continuous Integration server with Clean Install Every build, so it is little bit unproductive to have broken solution with every new version of any sub-dependency...

I think it should be STABLE = be able to build solution ANYTIME, any COMMIT in a project, because you have concrete dependencies in your package.json. Current behavior is, you are able to BUILD a project only several days, then you have to spend several hours to fix dependencies and usually - you have to upgrade your project everytime to the LATEST CLI, because of uncompatibility in @ngtools... as "^" dependency in compiler-cli and so on...

Please discuss about it, we all want to make the usage of CLI / Angular better and this benevolent versioning is the bad way in JS world, it only leads to unstable behavior with every build.

[delasteve]

I see your point. For client facing applications, I also tend to use pinned versions for the very reason you point out, it's stable. That said, removing the caret would lead to a lot more dependency management that the maintainers and contributors have to continually manage.

A discussion was had, earlier today in fact, about whether we care if the @angular/cli package is in dependencies or should we force it to be in devDependencies. I bring this up because the answer is relatable to your concerns. It boiled down to the following, if a user of the CLI has an issue with how dependencies are managed, the user is free to change it. You are able to remove the carets should you not want them in your package.json and it won't affect how the CLI operates.

[sumitarora]

Closing as per comment.

[montella1507]

@delasteve hello, thanks for answer. Yet am not sure i have written that correctly.
I am not talking about:
"@angular/cli": "^1.0.0-beta.32.3" in "my" package.json but about

"@angular/compiler": ">=2.3.1 <5.0.0", "@angular/compiler-cli": ">=2.3.1 <5.0.0", "@angular/core": ">=2.3.1 <5.0.0", "@angular/tsc-wrapped": ">=0.5.0 <5.0.0", "@ngtools/json-schema": "1.0.3", "@ngtools/webpack": "1.2.10",

in @angular/cli/package.json for an example..

I got i can "override" that by my "concrete version" in my package.json. If we know, that angular CLI ver. XYZ works great with @angular/compiler XYZ, shouldnt it be to be fixed to that version? You know.. they are really lot of uncompatibilities in versions.. So where is the problem to LOCK that to concrete version?

Im afraid i still didnt get it.
A! + B1 + C! works together, if you run your tests with pull requests, you know concrete versions when it works together, dont you? I am not so confident in this NPM deep dependencies so im not good partner to discussion but i have great experience with package managers from Maven, NuGet, Composer etc. (ofc it is little bit different situstion, because there are no source codes distributed)

[angular-automatic-lock-bot]

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.}