BigInt

BigInt est un type primitif JavaScript ajouté dans ES2020 pour l’arithmétique entière à précision arbitraire. Contrairement au type Number standard — qui utilise la double précision IEEE 754 et perd de la précision au-delà d’environ 2⁵³ — BigInt peut représenter des entiers de n’importe quelle taille.

Syntaxe littérale : ajoutez n à un nombre, ou appelez BigInt(x). Les opérateurs comme +, -, *, / fonctionnent, mais vous ne pouvez pas mélanger BigInt avec Number — 1n + 1 lève une exception. La division tronque vers zéro (division entière).

Où BigInt importe : montants Ethereum en Wei (jusqu’à 10¹⁸ par ETH), opérations cryptographiques (clés RSA, ECC), grands identifiants de bases de données (Snowflake, ULID), compteurs à grande échelle, systèmes financiers qui stockent les centimes sous forme d’entiers.

Notre convertisseur Wei / Gwei / ETH utilise BigInt partout pour que les montants en Wei à 18 chiffres fassent un aller-retour sans perte. Voir notre méthodologie crypto pour les détails d’implémentation.

Où Number échoue silencieusement avant BigInt : la limite est Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9 007 199 254 740 991. Au-delà, les entiers consécutifs ne sont plus tous représentables — 9007199254740992 et 9007199254740993 s’arrondissent au même double. Les parseurs JSON qui n’activent pas la prise en charge BigInt altèrent silencieusement les grands identifiants retournés par les API (identifiants Twitter Snowflake, identifiants d’objets Stripe dans les comptes 64 bits, montants Ethereum). La corruption est silencieuse : pas d’exception, pas d’avertissement, juste un nombre différent. JSON.parse peut être configuré avec une fonction de révision qui détecte les chaînes d’entiers et les convertit explicitement en BigInt.

BigInt et sérialisation : JSON.stringify(1n) lève une TypeError par défaut — JSON n’a pas de type BigInt. La solution pragmatique est de sérialiser les BigInt comme des chaînes décimales et de les ré-analyser côté consommateur, ce que fait chaque API RPC de blockchain (Ethereum retourne des chaînes hexadécimales, Solana retourne des chaînes décimales). Évitez la tentation de .toString() à la sortie et de Number() à l’entrée — cela complète un aller-retour par le type avec perte et détruit l’intérêt. Connexe : IEEE 754 (pourquoi 0.1 + 0.2 !== 0.3 dans le même langage), Wei, Gwei. Référence : Proposition TC39 BigInt.

Exemple pratique : arithmétique de solde ETH

Considérez un compte détenant 1,234567890123456789 ETH, stocké on-chain comme 1234567890123456789 Wei. En tant que Number JavaScript, cela devient 1234567890123456800 — les deux derniers chiffres ont disparu. L’erreur (environ 11 wei) est minime en termes fiduciaires, mais si vous additionnez de nombreux tels soldes lors d’une réconciliation comptable, le biais d’arrondi se cumule et le grand livre hors-chaîne diverge de la vérité on-chain. Avec BigInt : const bal = 1234567890123456789n; const fee = 21000n * 30n * 10n**9n; const net = bal - fee; — exact au wei près, sans perte. Le terme 10n**9n est un milliard, le multiplicateur gwei-vers-wei.

Performances et pièges

Les opérations BigInt sont plus lentes que Number — typiquement 10 à 100 fois selon la taille des opérandes — car elles touchent l’arithmétique à précision arbitraire dans V8 plutôt qu’une seule instruction CPU. Pour les boucles rapides sur des millions de valeurs tenant en toute sécurité dans un double, restez sur Number. Autres pièges : Math.max, Math.abs, Math.floor rejettent BigInt ; JSON.stringify lève une exception ; typeof 1n === "bigint", pas "number" ; mélanger des types avec < et === suit des règles de coercition surprenantes (1n == 1 est vrai, 1n === 1 est faux). La référence BigInt MDN énumère le tableau de coercition ; traitez-le comme une liste de vérification lors de l’introduction de BigInt dans une base de code auparavant uniquement Number.