Dependency free package?

[dotnetchris]

I noted some of the changes between 4 and 3 from the documentation, source, and just simply the dependencies i haven't specifically seen before.

I see one of the larger changes was the end of previous support for diff tool integration? (i wasn't even aware that was a feature nor something i could maybe need). That it was replaced with capabilities from DiffEngine. This is likely a good improvement especially for future interoperability, maybe these capabilities should be split to a Shouldy.Diff or Should.Contrib style package.

I simply uninstalled v4 and went with v3, i know this will always be an option. But figured people might appreciate a long term dependency free core.

[SimonCropp]

what is the value to consumers of making this change?

[dotnetchris]

People don't like package explosions, especially for small tools. The dependency chain for v4 is really egregious. There's just no need for it (personally the outcome is as of v4 I can't recommend this tool any longer).

Just as in the real world, I don't expect my screwdriver to have a monkey wrench hanging off the end.

[SimonCropp]

so v4 (in the .NETStandard 2.0 variant) increases the dependencies from 3 to 4. i am not sure if i would call that change now a "really egregious dependency chain".

Would u like the dependencies on System.Memory split into a diff package as well?

here's just no need for it

There was and is a need for it. It fixed several bugs, reduced the amount of duplicate code that needed to be maintained, make test and releasing shouldly less work. There was a discussion regarding it that went for several weeks #644

People dont like large dependency chains for specific reasons. eg mem usage, assembly load time, possible version/api conflics due to diamond dependencies. Perhaps you could express you concern, in this specific case, as to which one of those reasons apply and to what extent?

[SimonCropp]

let us know if you ever get around to a more detailed analysis