Open mickdekkers opened 6 years ago
Yeah, I found this to be quite confusing myself, PR welcome 👍
This change would be breaking. With that said I think we can support this by first checking if the path exists and if not then we see if the npm module exists in either the deps or dev deps. If it does then we can install it as a transient dependency first before running commit.
@mickdekkers @LinusU Does that sound right?
@jimthedev sounds interesting, what do you mean by "install it as a transient dependency"?
@mickdekkers I mean we would run npm install --no-save cz-my-adapter@1.2.3
. Effectively we would detect that the npm install hasn't been run yet and would install module. This ensures that the package.json and package lock is not touched but that commitizen could run.
One tricky thing is that npm changed from --save being implied at a certain version of npm so we might have to detect their npm version.
We are only talking about the generated config here, right? So I'm not sure if it would be considered breaking?
I also don't think we would need to install any dependencies automatically? Although that would potentially also be nice!
edit:
We are only talking about changing this line, right?
@LinusU yeah, that's my proposed solution. I think you may be right; since it only applies to initialization and doesn't affect existing projects, it shouldn't be a breaking change.
The setup instructions in the readme use the module name of the adapter (i.e.
cz-conventional-changelog
), but the actual config generated bycommitizen init
uses a relative path to the module:https://github.com/commitizen/cz-cli/blob/d5e24245dda078464d8c964f5d052bcad1da14f5/src/commitizen/adapter.js#L35-L41
According to the readme:
One downside of using a relative path is that developers cannot use their global commitizen install to create a commit if they have not yet run
npm install
in the repo, because this results in an error:This change should fix the issue, although I'm not sure whether it would be considered breaking: