Utiliser es-toolkit pour les utilitaires JavaScript du quotidien

Si vous avez déjà fait appel à Lodash pour debouncer une saisie, fragmenter un tableau ou extraire des clés d’un objet, vous connaissez déjà la valeur d’une bibliothèque d’utilitaires JavaScript bien conçue. La question qui mérite d’être posée aujourd’hui est de savoir si Lodash reste le choix par défaut pertinent, ou si une option plus légère convient mieux aux projets modernes basés sur TypeScript et ESM.

es-toolkit est une bibliothèque d’utilitaires JavaScript activement maintenue, conçue dès le départ avec TypeScript, ESM et les API JavaScript modernes en tête. Elle couvre les fonctions utilitaires que les développeurs frontend utilisent le plus souvent — et ce, avec une empreinte sensiblement plus petite que celle de Lodash.

Qu’est-ce que es-toolkit et pourquoi est-ce important ?

es-toolkit est une bibliothèque d’utilitaires JavaScript moderne qui propose des implémentations typées et tree-shakeables des fonctions utilitaires courantes. Elle est entièrement écrite en TypeScript, livre ses propres définitions de types et ne nécessite aucun paquet @types/ séparé.

Comme indiqué dans la documentation d’es-toolkit, la bibliothèque est déjà utilisée par des projets et écosystèmes tels que Storybook, Recharts, CKEditor, Material UI et Nuxt. Ce niveau d’adoption est un bon indicateur que le projet est activement maintenu et adapté à un usage en production.

La bibliothèque est organisée en catégories claires — utilitaires pour tableaux, objets, fonctions, chaînes, mathématiques et asynchrones — chacune dans son propre module. Cette structure facilite le tree-shaking avec n’importe quel bundler moderne.

Des fonctions utilitaires du quotidien, couvertes

Voici un aperçu pratique des types d’utilitaires que es-toolkit gère bien :

Utilitaires pour tableaux

import { chunk, groupBy, uniq, difference } from 'es-toolkit';

chunk([1, 2, 3, 4, 5], 2);                          // [[1, 2], [3, 4], [5]]
groupBy(['one', 'two', 'three'], (s) => s.length);  // { 3: ['one', 'two'], 5: ['three'] }
uniq([1, 2, 2, 3]);                                 // [1, 2, 3]
difference([1, 2, 3], [2, 3]);                      // [1]

Utilitaires pour objets

import { pick, omit, mapValues } from 'es-toolkit';

pick({ a: 1, b: 2, c: 3 }, ['a', 'c']);    // { a: 1, c: 3 }
omit({ a: 1, b: 2, c: 3 }, ['b']);         // { a: 1, c: 3 }
mapValues({ a: 1, b: 2 }, (v) => v * 2);   // { a: 2, b: 4 }

Utilitaires pour fonctions

import { debounce, throttle, once } from 'es-toolkit';

const handleSearch = debounce((query: string) => fetchResults(query), 300);
const handleScroll = throttle(() => updatePosition(), 100);
const initialize = once(() => setupApp());

Vérification de null et garde-types

import { isNotNil } from 'es-toolkit';

const values = [1, null, 2, undefined, 3];
values.filter(isNotNil); // [1, 2, 3] — typé comme number[]

TypeScript infère ici correctement le type restreint — ce qui demande davantage d’efforts manuels avec Lodash et @types/lodash.

Taille du bundle : une différence concrète

Lorsque vous importez une seule fonction depuis es-toolkit dans un projet Vite, seul le code de cette fonction est inclus dans le bundle. Selon l’utilitaire, la taille ajoutée au bundle peut être extrêmement faible comparée à des imports Lodash équivalents.

L’écart est le plus visible lorsque vous importez depuis le paquet lodash complet sans tree-shaking, ce qui peut ajouter plus de 20 ko compressés.

La différence compte le plus pour le JavaScript côté client, où la taille du bundle affecte directement le temps de chargement et les Core Web Vitals.

Migrer depuis Lodash

Si vous faites évoluer une base de code existante, es-toolkit fournit une couche de compatibilité :

// Avant
import _ from 'lodash';

// Après (mode compatibilité)
import _ from 'es-toolkit/compat';

es-toolkit/compat est testé avec la propre suite de tests de Lodash et vise une compatibilité totale avec Lodash. Cela dit, le paquet standard es-toolkit reste le meilleur choix sur le long terme — il est plus petit, plus rapide, et les types TypeScript sont plus précis.

Le paquet standard présente également une surface d’API plus restreinte et plus moderne que celle de Lodash, donc consulter la documentation officielle avant de grosses migrations reste une bonne idée.

Quand es-toolkit a-t-il du sens ?

Utilisez es-toolkit lorsque :

• Vous démarrez un nouveau projet TypeScript ou ESM et souhaitez des utilitaires typés sans dépendance lourde.
• La taille du bundle est une préoccupation et vous voulez un tree-shaking propre.
• Vous avez besoin d’aides asynchrones modernes comme delay avec prise en charge de AbortController.
• Vous voulez des types intégrés sans installer un paquet @types/ séparé.

Restez avec Lodash (ou le JavaScript natif) lorsque :

• Vous avez une large base de code Lodash existante et que le coût de migration l’emporte sur les bénéfices.
• Vous reposez sur des patterns spécifiques à Lodash dans toute une application ancienne.
• Votre environnement d’exécution est antérieur à l’outillage JavaScript moderne.

Conclusion

es-toolkit est une alternative à Lodash pratique et bien maintenue pour les projets JavaScript et TypeScript modernes. Elle ne remplacera pas immédiatement chaque flux de travail Lodash, mais pour les nouveaux projets — ou toute base de code où la taille du bundle et la sécurité des types comptent — elle mérite d’être considérée comme bibliothèque d’utilitaires par défaut.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before 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.