Consumers of the library may want to implement their own Signer or even catch and make assertions of errors. Exposing the classes from utils through this library means that consumers don't have to manually require the sub-package themselves, which helps avoid dependency resolution issues that can sometimes happen in npm when root projects and dependencies have slightly mis-matched version requirements.
In my view it's best for a package to export classes/interfaces/types it depends on (where possible) rather than have consumers import them manually through an explicit dependency definition.
I just noticed the constructor of SignPdf initializes byteRangePlaceholder which is never used. If it's not a problem for you, you can remove that in this same PR.
Consumers of the library may want to implement their own Signer or even catch and make assertions of errors. Exposing the classes from utils through this library means that consumers don't have to manually require the sub-package themselves, which helps avoid dependency resolution issues that can sometimes happen in npm when root projects and dependencies have slightly mis-matched version requirements.
In my view it's best for a package to export classes/interfaces/types it depends on (where possible) rather than have consumers import them manually through an explicit dependency definition.
eg:
is better than:
I can give examples of npm's dependency issues that I've experienced when doing this kind of thing.