Repository navigation
Document the reason behind adding package:crypto as a transitive dependency #228
Description
Thank you for maintaining this library!
A few concerns:
- Clarify
the older "package:crypto"in README
This section: https://pub.dev/packages/cryptography#cryptographic-hash-functions
While the performance comparison itself can be accurate,
readers might interpret the word "older" differently than what is intended.
It may indicate that this is a rewrite of package:crypto or that both are from the same publisher (they are different: dart.dev and dint.dev, which are a bit similar and easy to conflate) or that cryptography is an official successor.
Maybe it should indicate that both are different and solve different problems, but package:cryptography is a more complete solution for cryptography beyond hashing algorithms?
- Clarify the reason behind depending on
package:crypto
This is the part that I find a bit inconsistent with the former.
I assume this is for compatibility with the ecosystem, at least according to this quick GitHub search:
https://github.com/search?q=repo%3Adint-dev%2Fcryptography%20package%3Acrypto&type=code
So that it implements the classes and interfaces of package:crypto but in practice it is still a different implementation. Is that correct?
See also:
This is understandable, but Dart can be more specific: is it a pure Dart implementation, or an implementation of package:crypto's API by the Dart team publisher (commonly known as a Dart package)?
The first version of package:cryptography adds crypto as a dependency: https://pub.dev/packages/cryptography/versions/0.1.0
Note
These details are minor but raised some questions when choosing to adapt package:cryptography in other packages published to pub.dev. Real example: Skyost/SimpleSecureStorage#16 (comment)
The main concern was the additional transitive dependency: Dart's crypto (package:crypto).
Even though this does benefit from Dart tree shaking, so in practice this does not negatively impact the bundle size and many packages add package:crypto as a transitive dependency indirectly, breaking changes are still a concern.
Activity
EchoEllet commentedon Jul 22, 2026
I would be happy to send a PR, but I need to confirm my understanding.
Another question (off-topic) is whether this library plans to add Dart build hooks in the future, which may break Dart integration tests, scripts, and custom setup.
Dart integration tests are significantly faster and cheaper to run compared to Flutter integration tests. Pure Dart integration tests do not need to build a native app on each run, and in many cases, they can be completed in less than 1 second. Some plugins are slowly being refactored to be independent of Flutter method channels, so this is beneficial in practice (monorepo, CI, build failures).
One of the primary benefits of this package is that it decouples the Flutter-specific code from the Dart code. So I also assume there are no plans to add build hooks in
cryptography, or is this an inaccurate assumption?