Open JamesDelph opened 1 year ago
It isn't really possible to avoid any formatting changes between versions. Every release would end up being a new major release then. You could also have a 3rd teammate could come along and run resharper code cleanup on a file, which would definitely be different than what CSharpier produces.
In a team setting it really is ideal to use CSharpier as a local tool + enforce that any commits that make it to your main branch are formatted as csharpier expects. This documentation kind of covers that. But it could definitely be improved. And I think it also makes sense to have the main documentation discuss it as well.
I'm considering if it makes sense to change the IDE plugins to not have a global install option. Is that how you ended up with a different version than your co-worker?
I'm considering if it makes sense to change the IDE plugins to not have a global install option. Is that how you ended up with a different version than your co-worker?
Yeah. So in our repository I setup a pre-commit hook to run csharpier to check for any incorrectly staged files. I set it up about two weeks ago and done dotnet tool install -g csharpier
. My coworker done the same two days ago and got a newer version. Since the check is local (we've not set CI up yet) the pre-commit hook passed.
I've now set it up with the local tool installation to avoid the issue in the future.
I just encountered a situation in which I had csharpier 0.25.0 and a team member had 0.26.1 and the two versions produced different results.
Ideally, non-major releases shouldn't change the expected output, but I think this tool is fairly young, so until that is feasible please consider suggesting that users install csharpier as a local tool so that it can be version pinned in user's codebases to avoid such version issues.
Thanks