Migrate from ExcelJS to CmdCal XLSX

The hardest part of this migration is not API syntax. It is changing the mental model.

ExcelJS is great at imperative workbook mutation.

CmdCal XLSX is best when your application describes workbook intent as data.

What Changes

With ExcelJS, your code often looks like this:

  1. create workbook
  2. create worksheet
  3. add rows
  4. mutate widths, formats, borders, validations, and formulas
  5. serialize

With CmdCal XLSX, the end state is usually:

  1. map application data into workbook JSON
  2. validate the workbook contract
  3. render
  4. optionally preflight, validate, repair, or template-assemble

Migration Strategy

1. Start With One Export Family

Pick the workbook that hurts the most or changes the most often.

Do not migrate every workbook at once.

2. Separate Data Mapping From Workbook Shape

Create one function that returns business data, and another that converts it into CmdCal workbook JSON.

That separation is what makes the declarative model worth it.

3. Move Layout Decisions Into The Workbook Contract

Instead of mutating widths, tables, validations, and print settings piecemeal, describe them in the sheet definition.

4. Keep ExcelJS Where It Still Helps During Transition

If you have existing import logic or workbook-reading utilities, you do not need to remove those immediately. Many teams migrate generation first and keep the rest stable.

Common Pattern Mapping

ExcelJS PatternCmdCal XLSX Direction
worksheet.addRow(...)rows: [{ cells: [...] }]
cell-by-cell value mutationbuild the entire row/cell structure up front
post-hoc style mutationsheet/cell style in the contract
table creation via workbook APItables: [...] in the sheet
validation API callsdataValidations: [...] in the sheet
workbook write bufferSpreadsheetEngine.render(...)

Good First Target

The easiest export to migrate first is usually:

  • one or two worksheets
  • mostly tabular data
  • a small amount of styling
  • no complex template dependency yet

That gives you a clean win before you tackle heavier template-backed work.

What To Adopt Next

After the first export works, the next high-value steps are usually:

  • validateDocument(...)
  • preflight(...)
  • native tables
  • validation and repair for support flows
  • template parsing if the workbook layout is externally owned