Open up dependency range of colors

[webmaster128]

Right now, the dependency colors is fixed to "colors": "1.4.0". Thus, a project using jasmine-spec-reporter cannot install patch releases of colors without a new version of jasmine-spec-reporter. This also leads to multiple versions of colors installed in a larger project, which is unnecessary.

Could you open up the version range to "colors": "^1.4.0"? Thank you.

[bcaudan]

Hello @webmaster128!

Did you already encounter this specific issue?

I understand your point, however for now my take on this is that I prefer to keep control on how well jasmine-spec-reporter works with its dependencies, even if patch releases should theoretically not cause any issue.
Even if it is not super convenient, a workaround like force-resolutions could help to prevent the installation of multiple versions of colors.

Does it make sense?

[webmaster128]

Hello @bcaudan :)

I encountered those two issues multiple times in different dependencies in different projects:

1. My project installes multiple versions of the same dependency, leading to longer install times, more disk usage and, bigger caches in CIs (leading to slower runtimes again). This becomes especially annoying when each version of a dependency again pulls in multiple sub-dependencies.
2. A security fix was not applied because a dependencies pinned a dependency and then got poorly maintained or unmaintained.

I noticed this here when I saw that the upgrade to the latest jasmine-spec-reporter reduced the amount of dependencies because different versions of color were installed before (and will be again in the future).

I think it is best practice to assume there are not breaking changes within one semver major version series. If there are, you can blame the library maintainers. Version pinning is a way to explicitely protect again regression issues if they occur (i.e. pin to 1.4.0 only when there is a known problem with 1.4.1).

For the application using jasmine-spec-reporter there are lockfiles, to ensure the dependencies work nicely and deterministically. When dependencies are explicitely upgraded, they are tested. So I don't think this should be done by the library.

Even if it is not super convenient, a workaround like force-resolutions could help to prevent the installation of multiple versions of colors.

Yeah this can be done in extreme cases, e.g. when there is a detected security issue. But with many projects using thousands of dependencies, this method cannot be applied everywhere. Also, if a library author version pins a dependency, I need to assume there is a very good reason for it. Doing the reseach if this is the case is just too much.

[webmaster128]

Obsoleted by #696