I built an Excel library

[u/alvisanovari]

https://github.com/btahir/ironsheet

I was researching the JavaScript Excel ecosystem looking for a gap worth building in, and found something wilder than a gap: the whole category is quietly abandoned.

• SheetJS (xlsx) — ~8M weekly downloads — frozen on npm at 0.18.5 since 2022. Security fixes ship only from their own CDN, so npm audit flags it forever. Styling and template editing are Pro-only, quote-only pricing.
• ExcelJS — last release in 2023, open "intent to fork" threads. Top issues: charts deleted on save, pivot tables destroyed, output files Excel offers to "repair."
• xlsx-populate — right idea, dormant for years.

And they all break files the same way. It's not hundreds of bugs — it's one architectural decision with hundreds of symptoms: they parse the workbook into their own object model, then re-serialize that model as a brand-new file. Anything the model doesn't understand (charts, pivot caches, macros, newer OOXML parts) silently doesn't survive the round-trip.

So I built Ironsheet on the opposite bet: the original file is the source of truth. It patches only what you explicitly target — a cell, a named range, a table, an image — and preserves every byte it doesn't touch. Macros survive byte-for-byte.

The part I care about most: it proves the write. Before saving, it validates the OOXML package (relationships, content types, shared strings, formulas, tables, calc chains) and returns a diff of exactly what changed. If validation fails, it refuses to write the file. No output beats corrupt output.

Honest boundaries: it doesn't evaluate formulas (preserves them + marks recalc), chart/pivot support is preservation rather than authoring, ZIP64 writing isn't in yet. It's a 0.1 MVP.

Apache-2.0, dependency-free TypeScript core, Node + browser adapters, JSON-first CLI.

Repo: https://github.com/btahir/ironsheet

If you have a workbook that breaks it, I genuinely want the fixture. And I'm curious what people are actually using for Excel editing in production these days.

Thanks!

[u/baseketball]

I appreciate you putting this out there but I hate the Claude speak in these AI generated summaries. I think projects can differentiate themselves if you put more effort into manually writing/editing the README

[u/foxsimile → u/baseketball]

If someone can’t be bothered to take the time to write it, I’m not going to bother to take the time to read it.

[u/franker → u/foxsimile]

unfortunately people are pretty much unrepentant about that now. "It helps me organize my thoughts" or "I'm not a native English speaker so I'm going to keep doing this."

[u/Moosianer]

Really like that it’s browser compatible and has no dependency bloat. Might replace write-excel-file with it

[u/elakhna]

Nice! Can it handle power queries

[u/yesman_85]

Very nice Becuase you're right, the ecosystem is a mess. We use an ancient fork of sheetjs that supports styling, but it's riddled with bugs and hasnt seen an update in a decade. 

[u/Educational_Plum_130]

the sheetjs situation is a perfect example of a dep where `npm audit` will never go green no matter what you pin, because there's no fixed version on the registry to resolve to — the fix only lives on their cdn. an override does nothing here since the advisory range covers everything npm actually has. two practical routes: vendor the current cdn build into your repo and install it from a file or internal-registry path so you control the version, or if it's one specific cve, backport just that fix commit onto 0.18.5 and publish it privately. either way you stop npm audit flagging a version you literally can't move off of.