hucre : un moteur de feuille de calcul sans dépendance en TypeScript

Zéro dépendance et imports modulaires

hucre est un moteur de feuille de calcul écrit en TypeScript pur. Le README le décrit comme sans dépendance, ce qui signifie que le paquet lui-même n'importe aucune bibliothèque tierce. Les imports peuvent être limités à des sous-chemins comme hucre/xlsx ou hucre/csv, de sorte qu'un projet ne regroupe que le code qu'il utilise réellement. Le README inclut des tailles de bundle mesurées pour quelques combinaisons d'imports : uniquement l'analyse et l'écriture CSV donne environ 2,3 Ko (gzip), uniquement la lecture XLSX environ 32 Ko, et l'import de la bibliothèque entière environ 114 Ko. Ces chiffres proviennent de tests internes du projet et ne sont pas des benchmarks indépendants. La même section affirme que le code fonctionne dans Node, Deno, Bun, Cloudflare Workers et les navigateurs, mais le README ne fournit pas de matrice de tests pour étayer cette affirmation.

Lire et écrire des classeurs

L'API principale expose readXlsx et writeXlsx pour XLSX, ainsi qu'une fonction read unifiée qui détecte automatiquement XLSX, XLSB, XLS et ODS. Les options de lecture permettent de filtrer les feuilles par index, nom ou prédicat basé sur la visibilité, d'activer l'analyse des styles et de choisir un système de dates. Le côté écriture accepte un modèle de feuille avec colonnes, lignes et objets de données. Le README énumère une longue liste de fonctionnalités prises en charge : styles de cellules, cellules fusionnées, volets figés et fractionnés, filtre automatique, validation des données, hyperliens, images, commentaires, tableaux, mise en forme conditionnelle, plages nommées, paramètres d'impression, sauts de page, protection de feuille, texte enrichi, formules partagées et matricielles, sparklines, zones de texte, images d'arrière-plan, formats de nombres, feuilles masquées, cases à cocher natives Excel 2024, et export vers HTML, Markdown, JSON et TSV. Ce sont des affirmations du README ; le dépôt ne contient pas de rapport de conformité séparé.

Traitement en streaming des gros fichiers

Pour les grands classeurs, hucre fournit streamXlsxRows pour la lecture et writeXlsxStream plus XlsxStreamWriter pour l'écriture. Le lecteur en streaming analyse l'archive ZIP de bout en bout et peut accepter directement un ReadableStream, en revenant à la mise en mémoire tampon uniquement lorsque la disposition de l'archive empêche un traitement en un seul passage. L'écrivain en streaming émet des octets au fur et à mesure que les lignes sont extraites d'un itérable, ce qui maintient la mémoire de pointe plate. Le README inclut des mesures issues d'un test Node 24 avec cinq colonnes de données mixtes : à 300 000 lignes, writeXlsxStream a atteint un pic de tas de 41 Mo tandis que XlsxStreamWriter a atteint 328 Mo ; à un million de lignes, l'écart était de 67 Mo contre 1 037 Mo ; à trois millions de lignes, l'écrivain tamponné a été jugé non viable. Le README note également que les chaînes sont écrites en ligne par défaut, que les enregistrements ZIP64 sont désactivés tant qu'ils ne sont pas activés, et que la compression repose sur CompressionStream de la plateforme, sans lequel les pièces sont stockées non compressées.

Préservation aller-retour et formats hérités

Le README distingue deux chemins : openXlsx et saveXlsx copient octet pour octet chaque partie que hucre ne régénère pas, donc les graphiques, les macros VBA et d'autres contenus non modélisés survivent à une modification. En revanche, la paire readXlsx et writeXlsx reconstruit le classeur à partir d'un modèle, et seul ce que ce modèle décrit ressort. Cela compte lors de l'édition de fichiers à macros, car readXlsx/writeXlsx ne préservera pas vbaProject.bin. La bibliothèque lit également les anciens fichiers XLS et XLSB, mais uniquement pour les noms de feuilles, les valeurs de cellules et les fusions. Les formules apparaissent comme valeurs en cache, jamais comme texte de formule, et les styles, largeurs de colonnes, hauteurs de lignes, visibilité, plages nommées et propriétés du classeur sont ignorés. Le README indique qu'une conversion depuis ces formats est donc une conversion de valeurs et de noms de feuilles, pas une copie fidèle.

Support ODS avec un modèle volontairement restreint

Le lecteur et l'écrivain ODS modélisent le même ensemble limité de fonctionnalités, donc un fichier ODS lu et réécrit est sans perte. Le problème apparaît lors de la conversion de XLSX en ODS : les valeurs, les formules, les fusions et six facettes de style de cellule (gras, italique, taille de police, couleur de police, couleur de fond, format de nombre) sont conservées, tandis que les bordures, l'alignement, les largeurs de colonnes, les volets figés, la validation, les plages nommées, les images et la mise en page sont supprimés silencieusement. Le lecteur n'ouvre que content.xml et meta.xml, pas styles.xml ni settings.xml, donc un fichier LibreOffice avec des styles nommés ne revient qu'avec sa mise en forme directe. Le README présente cela comme le contrat actuel et note que l'élargissement du modèle ODS est un travail ouvert.

Graphiques, tableaux croisés dynamiques et autres internes du classeur

hucre gère plusieurs parties internes d'un classeur que la plupart des bibliothèques évitent. Les graphiques font un aller-retour à travers un enregistrement Chart côté lecture, un SheetChart côté écriture et un assistant cloneChart qui applique des surcharges typées. Le côté écriture ne crée que sept types de graphiques (barre, colonne, ligne, camembert, anneau, nuage de points, aire) et lève une exception pour les autres, tandis que le côté lecture peut analyser les graphiques combinés et d'autres types. Les tableaux croisés dynamiques peuvent être lus et créés structurellement, mais l'écrivain émet le cache et la disposition sans cellules de valeur précalculées, laissant Excel les calculer à la première ouverture. Les slicers, les filtres de chronologie, les références externes de classeur et les images de cellules WPS sont lus dans des modèles typés et redéclarés lors de l'enregistrement pour survivre à l'aller-retour, bien que la synthèse fraîche de certaines de ces parties soit encore listée comme travail de suivi.

API unifiée, CLI et fonctions utilitaires

Le paquet comprend également des assistants en complément haut niveau : read et write détectent automatiquement le format, et readObjects et writeObjects convertissent entre les feuilles de calcul et des tableaux d'objets avec en-têtes. Une CLI est disponible via npx hucre, avec les commandes convert, inspect et validate ; le README montre que convert accepte XLSX, ODS, CSV, TSV, XLS et XLSB en entrée, et écrit les quatre premiers, car XLS et XLSB sont en lecture seule. Les opérations de feuille en mémoire incluent insertRows, deleteRows, cloneSheet et moveSheet. Il existe des fonctions d'export HTML et Markdown, un analyseur fromHtml pour lire les tableaux, un rendu de format de nombre, des utilitaires de référence de cellule et un WorkbookBuilder fluide. Le README insiste sur le fait que les exports Markdown et HTML sont à sens unique, qu'il n'y a pas de fromMarkdown et que fromHtml n'est pas l'inverse de toHtml.

Tester hucre sur son entrée réelle

Pour hucre, le contrôle utile doit rester attaché au dépôt productdevbook/hucre. Reprenez un exemple, une commande ou un fichier cité dans le README et exécutez le scénario dans un environnement isolé. Observez l'entrée, la sortie, les erreurs, les permissions et les fichiers produits. Comparez le résultat avec ce que le document annonce, sans transformer une démonstration en garantie de compatibilité, de sécurité ou de performance. Les paramètres que hucre ne décrit pas restent à établir dans votre contexte. Un essai portant sur hucre, avec sa branche main et ses dépendances réelles, permet de distinguer une capacité documentée d'une hypothèse d'intégration. Cette trace est particulièrement importante lorsque le projet est un guide, une démonstration ou un composant destiné à un autre système.

Conclusion éditoriale

hucre convient aux lecteurs dont le besoin correspond exactement aux fichiers, commandes et environnements décrits dans son README. Il convient moins à une équipe qui attend des garanties absentes du dépôt. Commencez par hucre, utilisez l'exemple ou l'entrée documentée, puis observez la sortie, les erreurs et les droits nécessaires avant d'élargir l'usage.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes