Replies: 1 comment 11 replies
-
|
Hi. There is no need to follow angular versions, because ng-mocks doesn't depend on angular implementation and works with any angular version (apart from latest features which should be added to ng-mocks). Semantics is used in case of dependency when each lib version depends on a specific angular implementation, whereas that's not the case for ng-mocks. |
Beta Was this translation helpful? Give feedback.
-
|
Also, I never mentioned |
Beta Was this translation helpful? Give feedback.
-
|
I wish There are enterprises which are on very old angular versions and don't follow the way Google deprecates Angular. In the same time, I don't get why they should jump from |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I know that there are companies that don't follow the normal migration timeline, that is not my point. I'm going use the reverse example. This functionality would not make sense in a version without signals. However, it would be exposed by ng-mocks for those applications. This could generate confusion or other issues. |
Beta Was this translation helpful? Give feedback.
-
|
This is the way
in case of
it doesn't work for enterprises, there are many companies which still use very old angular versions. For
In a company - yes. In my case, it's more about availability to fix something in spare time. Unfortunately, as you can see, I've been busy for quite a while. And, I hope it is going to be changed soon, so I can contribute more. Until then an easy fix will be of a higher priority due to the less time required.
Again - it doesn't cost much to support older versions.
|
Beta Was this translation helpful? Give feedback.
-
|
So basically the issue is that what I'm requesting requires to much work for you. Which is funny soccer to me, I would like to contribute to this lib, but having to install dependencies every day (constant pr`s for minor stuff) and just running this lib, is a nightmare. There is no explanation in the code for why something's are how they are, there is no model that explains the idea behind stuff. It has a very high barrier of every for a new contributor. As a result, you get the situation you are in now. You are the only active maintainer and I, who want to contribute, don't because I don't understand several decisions of the lib and everything is dependent on you. As an example, I wanted to contribute with schematics, but never got a response. My goal with this discussion was to be able to remove stuff from the lib, so that others like myself can contribute to it. I will stop annoying you since there doesn't seem to a way to convince you and you're already with a lack of time. |
Beta Was this translation helpful? Give feedback.
-
Background
When ngMocks was created, it was just a normal testing library, as time moved on, it improved into being one of the most used libraries for testing in the angular ecosystem. However, its development doesn't follow the normal development from the majority of Angular libraries like Angular Material and others.
As you can see in the official docs, the latest version can be tested against an Angular 5 application.
Proposal
I would like to propose that ngMocks follows the Angular team versioning logic such that we would have:
--
Advantages
Following the standard versioning system
The current versioning system doesn't exist for this library, it tries to keep all possible versions happy. This increases the difficulty to add new features or fix changes that occur when the Angular Team adds big functionalities, example: the addition of the new
input.requiredthat created several issues in the repository.Less need for distinct behavior between versions
With a focus on the last 3 versions, there is less of a need to test against old specs for errors that break only in old versions of Angular that are not unsupported. This does not mean that the library would not add patches to these versions (see next advantage).
Better bug prioritization
A bug on the latest version of Angular is not as important as a bug on an older and unsupported version.
This would help maintain the library since bugs in old version could take a reduced importance versus new changes that will remain going forward.
Reduced dimension and easier maintainability
This library tests its functionality versus several issues, some of which only occur in very old versions of Angular that are no longer supported. Keeping these files for newer versions doesn't bring much value and adds dimension to the library.
With the goal of making the library easier to maintain, reducing the dimension would help new developers to contribute and lighten the weight on @satanTime.
More predictable package.json behavior
It is a bit strange well Angular changes from version x.y.z to x+1.0.0, and the library keeps the same version.
For users who are migrating their applications, some may lose time checking if the library keeps up to date. By following the same version as the Angular team for the main branch, it makes the migration behavior more predictable for existing applications.
Beta Was this translation helpful? Give feedback.
All reactions