49f3442e5c
Publishing under upstream's exact version was not merely confusing in a lockfile — it was unsafe. @polkadot/util-crypto pins @polkadot/networks at an exact version, and @polkadot/keyring pins util-crypto the same way. With every fork numbered 14.0.3, a consumer that forgot one resolution would have yarn quietly satisfy that pin from npm: the *unforked* upstream package, installing cleanly, with no Quantus network entry or no isDilithium, and nothing to indicate anything was wrong until something failed much later for an unrelated-looking reason. Renaming the forks makes that a resolution failure instead. Verified by deleting the @polkadot/networks resolution in quantus/ui and running an install: YN0082: @polkadot/networks@npm:14.0.3-quantus.1: No candidates found Unforked dependencies keep upstream's numbers — @polkadot/util, x-bigint, x-randomvalues, wasm-* — because they come from npm and should. Published with `--tag quantus`, which npm requires for a prerelease version and which is the honest dist-tag anyway: these are not upstream's `latest`. The tag is informational, since consumers pin by tarball URL. The old 14.0.3 artifacts have been deleted from the registry so nothing can resolve to them. Refs quantus/extension#2 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012uDUodEcRbBwNRi3UCmw8f
@polkadot/keyring
Key management of user accounts including generation and retrieval of keyring pairs from a variety of input combinations.
Usage
Installation -
yarn add @polkadot/keyring
Classes and Functions can be imported as follows:
import Keyring from '@polkadot/keyring';