Quand Pourriez-Vous Avoir Besoin de BigInt en JavaScript ?

JavaScript gère la plupart des nombres sans problème — jusqu’à ce que ce ne soit plus le cas. Si vous avez déjà récupéré un identifiant volumineux depuis une API et remarqué qu’il revenait légèrement incorrect, ou tenté d’effectuer des opérations arithmétiques précises avec un très grand entier et obtenu un résultat subtilement erroné, vous avez déjà rencontré le problème que BigInt résout.

La Limite Que les Nombres JavaScript Ne Peuvent Franchir

Tous les nombres JavaScript utilisent le format virgule flottante double précision IEEE 754. Cela vous donne une plage d’entiers sûrs de −(2⁵³ − 1) à 2⁵³ − 1, représentée par Number.MIN_SAFE_INTEGER et Number.MAX_SAFE_INTEGER.

Au-delà de cette limite, les entiers perdent silencieusement leur précision :

console.log(9007199254740991 + 1)  // 9007199254740992 ✅
console.log(9007199254740991 + 2)  // 9007199254740992 ❌ (incorrect)

// Voici le problème de précision en action :
9007199254740992 === 9007199254740993 // true — ils sont identiques pour JavaScript

Aucune erreur n’est levée. La valeur est simplement incorrecte. C’est le problème de limite de précision que BigInt a été conçu pour résoudre.

Ce Qu’est Réellement BigInt

BigInt est un type primitif JavaScript intégré, introduit dans ES2020, qui peut représenter des entiers de taille arbitraire, limités uniquement par la mémoire disponible. Vous en créez un en ajoutant n à un littéral entier ou en utilisant le constructeur BigInt() :

const big = 9007199254740993n                 // syntaxe littérale
const alsoBig = BigInt("9007199254740993")    // constructeur avec chaîne

9007199254740992n === 9007199254740993n        // false ✅ — correct

Une contrainte importante : BigInt est réservé aux entiers uniquement. Il ne peut pas représenter de décimales ou de valeurs fractionnaires. 1.5n lève une SyntaxError.

Quand Utiliser BigInt en JavaScript

La plupart du code frontend n’a jamais besoin de BigInt. Mais quelques scénarios réels l’exigent véritablement.

Identifiants volumineux provenant de systèmes externes. Le système Snowflake ID de Twitter et les schémas d’identifiants distribués similaires produisent des entiers 64 bits qui dépassent Number.MAX_SAFE_INTEGER. Lorsqu’une API REST renvoie l’un de ces identifiants comme nombre JSON, JavaScript le corrompra silencieusement. L’analyser comme une chaîne et le convertir en BigInt préserve exactement la valeur.

// Un ID 64 bits reçu comme chaîne depuis une API
const userId = BigInt("922337203685477580")

Entiers 64 bits provenant de WebAssembly. Le type i64 de WebAssembly correspond directement à BigInt en JavaScript. Si votre module Wasm renvoie ou accepte des entiers 64 bits, vous aurez besoin de BigInt pour les gérer correctement.

Arithmétique exacte sur entiers où la précision ne doit jamais faillir. Certaines valeurs de transactions blockchain, de grands compteurs, ou l’arithmétique de timestamps haute précision (par exemple, nanosecondes depuis l’epoch) peuvent dépasser la plage d’entiers sûrs. BigInt conserve chaque chiffre exact.

Contraintes Importantes à Connaître

Avant d’utiliser BigInt, comprenez ses limitations :

Vous ne pouvez pas mélanger BigInt et Number dans les opérations arithmétiques. Cela lève une TypeError. Une conversion explicite est requise :

const big = 10n
const num = 5

big + num            // ❌ TypeError
big + BigInt(num)    // ✅ 15n
Number(big) + num    // ✅ 15 (mais perd la précision BigInt pour les grandes valeurs)

L’API Math ne fonctionne pas avec BigInt. Math.max(), Math.sqrt(), et toutes les autres méthodes Math lèveront une erreur si on leur passe un BigInt. Si vous avez besoin de ces opérations, vous devrez convertir — et accepter le compromis de précision.

La sérialisation JSON échoue par défaut. JSON.stringify() lève une TypeError sur les valeurs BigInt. Vous avez besoin d’un replacer personnalisé ou d’une méthode toJSON() pour gérer la sérialisation :

BigInt.prototype.toJSON = function () {
  return this.toString()
}

JSON.stringify({ id: 922337203685477580n }) // '{"id":"922337203685477580"}'

Notez que cela convertit la valeur en chaîne dans la sortie JSON, que le système récepteur doit gérer en conséquence. De plus, modifier un prototype intégré comme BigInt.prototype est généralement déconseillé dans le code de production. Une fonction replacer personnalisée passée à JSON.stringify() est une alternative plus sûre :

const data = { id: 922337203685477580n }

JSON.stringify(data, (key, value) =>
  typeof value === "bigint" ? value.toString() : value
) // '{"id":"922337203685477580"}'

Conclusion

BigInt vs Number en JavaScript n’est pas vraiment une compétition — ils servent des objectifs différents. Utilisez Number pour tout ce qu’il gère bien, ce qui représente la plupart des cas. Recourez à BigInt spécifiquement lorsque vous travaillez avec des entiers qui peuvent dépasser 2⁵³ − 1 et où l’exactitude est non négociable. C’est une catégorie étroite mais importante, et BigInt la gère parfaitement.

FAQ

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.