The published npm tarball vendors a full copy of SheetJS under modules/xlsx/, which is about 7.4 MB of the 9.3 MB that alasql@4.17.3 occupies once installed — roughly 80% of the package, carried by every consumer whether or not they touch a spreadsheet.
Measured on alasql@4.17.3:
$ du -sh node_modules/alasql
9.3M node_modules/alasql
$ du -sh node_modules/alasql/*
7.4M node_modules/alasql/modules # all of it modules/xlsx
1.8M node_modules/alasql/dist
28K node_modules/alasql/README.md
Confirmed present in the published artifact rather than only in a working tree:
$ npm pack alasql@4.17.3
$ tar -tzf alasql-4.17.3.tgz | grep -c 'modules/xlsx'
24
including modules/xlsx/dist/xlsx.full.min.js and modules/xlsx/xlsx.mjs.
Why it is worth raising
xlsx is already declared in devDependencies, and the SheetJS integration is optional at the API level — a consumer only reaches it via the Excel import/export paths. But the vendored copy is unconditional, so the cost lands on everyone.
Our own case is probably a common one: alasql arrives as a transitive dependency (we do not depend on it directly), and the code path that would use it is behind a lazy require. We measured a running process with zero open file handles under alasql/ — the package is on disk and never executed, and 7.4 MB of that is a spreadsheet library in a workload with no spreadsheets.
Possible directions
- Declare
xlsx an optionalDependency and resolve it at runtime instead of vendoring, so npm fetches it only where it is wanted. This is the smallest change and keeps the current API intact for anyone who has it installed.
- Publish the Excel bridge as a companion package (
alasql-xlsx or similar), leaving the core lean and the integration explicit.
- If the vendored copy is deliberate — pinning a known-good SheetJS build, or working around a resolution problem — a note in the README would help. Consumers auditing install weight currently have no way to tell an intentional trade-off from an oversight, and the guessing is what generates issues like this one.
Happy to test a change against a real install and report measured before/after numbers if that would help. No urgency from our side — the cost is disk only, and we are raising it because it is invisible to most consumers rather than because it is blocking us.
Related but not the same: #352 (2015) concerned test fixtures in the git repository and was resolved by moving them to a separate repo; #157 tracks minifying the library itself. Neither covers the vendored module directory in the published tarball.
The published npm tarball vendors a full copy of SheetJS under
modules/xlsx/, which is about 7.4 MB of the 9.3 MB thatalasql@4.17.3occupies once installed — roughly 80% of the package, carried by every consumer whether or not they touch a spreadsheet.Measured on
alasql@4.17.3:Confirmed present in the published artifact rather than only in a working tree:
including
modules/xlsx/dist/xlsx.full.min.jsandmodules/xlsx/xlsx.mjs.Why it is worth raising
xlsxis already declared indevDependencies, and the SheetJS integration is optional at the API level — a consumer only reaches it via the Excel import/export paths. But the vendored copy is unconditional, so the cost lands on everyone.Our own case is probably a common one: alasql arrives as a transitive dependency (we do not depend on it directly), and the code path that would use it is behind a lazy
require. We measured a running process with zero open file handles underalasql/— the package is on disk and never executed, and 7.4 MB of that is a spreadsheet library in a workload with no spreadsheets.Possible directions
xlsxanoptionalDependencyand resolve it at runtime instead of vendoring, so npm fetches it only where it is wanted. This is the smallest change and keeps the current API intact for anyone who has it installed.alasql-xlsxor similar), leaving the core lean and the integration explicit.Happy to test a change against a real install and report measured before/after numbers if that would help. No urgency from our side — the cost is disk only, and we are raising it because it is invisible to most consumers rather than because it is blocking us.
Related but not the same: #352 (2015) concerned test fixtures in the git repository and was resolved by moving them to a separate repo; #157 tracks minifying the library itself. Neither covers the vendored module directory in the published tarball.