Requesting ECMAScript module (ESM) bundle support
See original GitHub issueEDIT: When this issue was raised, the module only shipped with a CommonJS / UMD build. Projects using Webpack or other bundlers used the default import syntax to pull the CommonJS build:
// old way
import XLSX from "xlsx";
v0.18.1 activated the ESM build for common tooling. See https://docs.sheetjs.com/docs/installation/frameworks for more details. The literal equivalent of the old import is
// new way
import * as XLSX from "xlsx";
import * as cptable from 'xlsx/dist/cpexcel.full.mjs';
XLSX.set_cptable(cptable);
Tree Shaking is supported with the ESM build!. If a project is only exporting XLSX files (using utils
and writeFile
), using named imports with writeFileXLSX
drastically reduces bundle size:
import { utils, writeFile } from "xlsx";
Sheet.js is providing the following warning in the Angular CLI for the new v10 release:
Starting with Angular 10 the Angular CLI now provide warnings for CommonJS modules. Read more about it here: https://blog.angular.io/version-10-of-angular-now-available-78960babd41
When you use a dependency that is packaged with CommonJS, it can result in larger slower applications. Starting with version 10, we now warn you when your build pulls in one of these bundles. If you’ve started seeing these warnings for your dependencies, let your dependency know that you’d prefer an ECMAScript module (ESM) bundle.
And here: https://angular.io/guide/build#configuring-commonjs-dependencies
It is recommended that you avoid depending on CommonJS modules in your Angular applications. Depending on CommonJS modules can prevent bundlers and minifiers from optimizing your application, which results in larger bundle sizes. Instead, it is recommended that you use ECMAScript modules in your entire application. For more information, see How CommonJS is making your bundles larger
They reference the following article regarding the issues with CommonJS: https://web.dev/commonjs-larger-bundles/
Additionally I’ve seen a few discussions by Angular staff members on Github discussing potentially dropping CommonJS support by default, and making it an opt-in feature in the future.
I realize the Angular team is taking a very strong armed approach here, but their reasoning seems solid. Needless to say I’d love to see ESM support if possible. Thanks!
Issue Analytics
- State:
- Created 3 years ago
- Reactions:44
- Comments:21 (6 by maintainers)
Top GitHub Comments
I’m running into this same issue. The resulting file is very large (725kB) and slow. If we could get this working as an ES module, it would help a lot.
Was this issue solved? I work with Angular as well 😃