For both the v1 branch and the v2-beta branch, the ethers library is marked as a peerDependency of the siwe package (in package.json). The usage of peerDependencies is used for packages that have a "plugin"-style architecture that need the things they extend to be installed "alongside" them rather than "under" them (documentation).
The siwe package uses the Ethers library's utility functions, but does not appear to add to the Ethers object (it's not a plugin for Ethers) and it doesn't return any Ethers-style objects (e.g. doesn't return an Ethers provider or Contract to the client). So, I believe ethers should be defined as a dependency rather than a peerDependency. Moving ethers to a dependency would allow siwe to use whatever version of ethers it wants (e.g. an older or newer version than what the implementing client app uses).
For both the v1 branch and the v2-beta branch, the
etherslibrary is marked as apeerDependencyof thesiwepackage (in package.json). The usage ofpeerDependenciesis used for packages that have a "plugin"-style architecture that need the things they extend to be installed "alongside" them rather than "under" them (documentation).The
siwepackage uses the Ethers library's utility functions, but does not appear to add to the Ethers object (it's not a plugin for Ethers) and it doesn't return any Ethers-style objects (e.g. doesn't return an EthersproviderorContractto the client). So, I believeethersshould be defined as adependencyrather than apeerDependency. Movingethersto adependencywould allowsiweto use whatever version ofethersit wants (e.g. an older or newer version than what the implementing client app uses).