Description
At present, all releases of cz-conventional-changelog since 3.0.1 are useless since they behave exactly as if 3.0.1 was installed.
The reason for this is the circular dependency between cz-conventional-changelog and commitizen. Since there is a circular dependency, one of the projects must always depend on an older version of the other. commitizen depends on cz-conventional-changelog =3.0.1 (no version range), so the modules get installed like this:
node_modules
commitizen (v4.0.3)
node_modules
cz-conventional-changelog (v3.0.1)
cz-conventional-changelog (v3.1.0)
When the user runs git-cz
, commitizen resolves cz-conventional-changelog from its own node_modules
, and thus always gets v3.0.1, no matter what version the user's package depends on.
The most annoying consequence of this problem for me personally is that even though my projects depend on cz-conventional-changelog v3.1.0 I am still seeing "improvement" in the list of change types, even though that type was removed some time ago.
This circular dependency will also likely cause you endless churn from Greenkeeper as Greenkeeper alternately updates commitizen and cz-conventional-changelog to update to the latest version of the other project, which will trigger a release, which will trigger Greenkeeper to update the other project, and so on, endlessly. Likely the only reason this has not happened already is that the build is failing for commitizen/cz-cli#657.
Some ideas for fixing this:
- Remove the dependency on commitizen from cz-conventional-changelog. Perhaps commitizen could instead pass an instance of configLoader to plugins. I don't think it is a good idea for plugins to have to depend on commitizen for this.
- Change the dependency on cz-conventional-changelog from commitizen to a
^
range dependency (although this will probably not fix the potential for Greenkeeper churn). - Remove the dependency on cz-conventional-changelog from commitizen - is this really required?