SheetJS moved its source off GitHub, so the repository you clone is a mirror frozen at one commit

The master branch is complete only through commit 515d1c6

The opening note in the repository is addressed to a linter rather than to a user, and it tells you the important thing. The new source repository is at https://git.sheetjs.com/sheetjs/sheetjs, issues are raised there, and the master branch of the GitHub repository includes all commits through 515d1c6f2e1d3ca422ee9198b177cfd926434936. The last push to that GitHub repository is dated 2024-04-18, and it has no GitHub releases. Consequence: cloning from GitHub gives you a prefix of the history, not the project, and a version number alone will not tell you which prefix you have. If you need to reason about what changed, that commit id is the only anchor the repository gives you, and tracking upstream means moving to the self-hosted repository rather than watching the GitHub one.

The npm package is called xlsx, and its only executable is a single njs script

The package manifest names the project xlsx, not sheetjs, and the name is what you install. What the manifest declares is this:

"name": "xlsx",
"version": "0.18.12",
"bin": {
	"xlsx": "./bin/xlsx.njs"
},
"main": "xlsx.js",
"module": "xlsx.mjs"

The version sits at 0.18.12, below 1.0, which npm treats as pre-1 with no compatibility promise attached. Consequence: the command the package puts on your PATH is called xlsx, the same word people use for the file format itself, so in scripts and documentation the library name and the file extension collide. Anyone who searches for a package named sheetjs and finds nothing is looking for the wrong name, and the repository prints no install line, so the package name is the only signal you get.

The exports map splits one library into four entry points and two addon bundles

The exports field is the widest part of the manifest. The root entry offers three conditions, an import of ./xlsx.mjs, a require of ./xlsx.js and types from ./types/index.d.ts, and there are separate subpaths for ./xlsx.mjs and ./xlsx.js so deep imports keep their own type declarations. Two further families of subpaths point at dist/xlsx.zahl variants with types at ./dist/zahl.d.ts, and dist/cpexcel variants with types at ./dist/cpexcel.d.ts, each split again into a full build and a plain build with distinct .mjs and .js files. Consequence: importing a subpath bypasses the root entry and lands on a different file with its own type declaration, so two imports of the same project can resolve to two type definitions, and a bundler that honors export conditions will pick the ESM file while a CommonJS consumer gets the other one.

The browser field replaces five Node built-ins with empty modules

One manifest field explains how the same files serve a server and a page:

"browser": {
	"buffer": false,
	"crypto": false,
	"stream": false,
	"process": false,
	"fs": false
}

Each of those five names is mapped to false, which tells a bundler to substitute an empty module for the real built-in. Consequence: a browser build of this library cannot touch the filesystem, and it cannot use Node's crypto, so certificate or key handling has to be done before the bundle runs. The substitution is silent rather than an error, which means a code path that reaches for one of these in a page fails at the point of use instead of at build time, and you get a stub where you expected a module.

Zero dependencies and sideEffects false cut in opposite directions

Two more manifest lines describe the shape of the package. The dependencies object is present and empty, so installing this project pulls nothing else into your tree, and every byte of behavior comes from files inside the package. The other line is sideEffects set to false, which is a promise to bundlers that no module in this package needs to run for its effect alone. Consequence: the empty dependency list is the one part of this manifest you can verify by reading it, and it is a real answer to the safety question, since there is no transitive supply chain to audit. The sideEffects flag cuts the other way. If any part of the library works by being loaded rather than by a value you reference, a tree-shaking bundler is entitled to delete it, and the symptom is a missing registration rather than a build error.

Styling, formulas and PivotTables are the paid product, not a roadmap

The offering is split in two and the line is explicit. The Community Edition covers extracting data from complex spreadsheets and generating new spreadsheets that work with legacy and modern software. SheetJS Pro, linked from sheetjs.com/pro, covers editing complex templates, styling, custom sheets with images, graphs and PivotTables, evaluating formula expressions and porting calculations to web apps, and automating spreadsheet tasks. Consequence: if your requirement is a styled workbook or a computed cell, the open source package will not grow that feature, because it is the thing being sold. The license section reinforces the boundary by stating that all rights not explicitly granted by the Apache 2.0 License are reserved by the Original Author, and by directing you to the LICENSE file rather than summarizing it.

The top-level tree is a stub, and the type definitions target a Node 8 era

What sits at the top of the repository is short: .github/, LICENSE, README.md, demos/, package.json and test_files. There is no source directory and no build configuration, so the implementation is not readable from this copy, and an audit, a fork or a patch has to happen at the self-hosted repository. The only artifacts you can inspect here are the demos and the test_files directory of spreadsheet fixtures. The visible development dependencies are @sheetjs/uglify-js at ~2.7.3 and @types/node at ^8.5.9, and that Node type major is worth noticing: the type definitions were written against a runtime from several generations back, so Node APIs introduced since then are absent from the shipped types even when the runtime supports them.

Editorial conclusion

Use SheetJS CE when you need to read and write spreadsheet files in JavaScript and you want a package that pulls in nothing else, which the empty dependencies block makes verifiable by inspection. Do not reach for it to produce styled output, evaluate formulas, or build PivotTables, because those are sold separately as SheetJS Pro. Before you depend on it, decide which source you are pinning, since the GitHub copy last received a push on 2024-04-18 and the repository carries no GitHub releases at all, and read the LICENSE file rather than the summary in the readme, since the license section reserves every right the Apache 2.0 text does not explicitly grant.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository