You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Paul Taylor (Jira)" <ji...@apache.org> on 2020/10/09 21:44:00 UTC

[jira] [Created] (ARROW-10255) [JS] Reorganize imports and exports to be more friendly to ESM tree-shaking

Paul Taylor created ARROW-10255:
-----------------------------------

             Summary: [JS] Reorganize imports and exports to be more friendly to ESM tree-shaking
                 Key: ARROW-10255
                 URL: https://issues.apache.org/jira/browse/ARROW-10255
             Project: Apache Arrow
          Issue Type: Improvement
          Components: JavaScript
    Affects Versions: 0.17.1
            Reporter: Paul Taylor
            Assignee: Paul Taylor


Presently most of our public classes can't be easily [tree-shaken|https://webpack.js.org/guides/tree-shaking/] by library consumers. This is a problem for libraries that only need to use parts of Arrow.

For example, the vis.gl projects have an integration test that imports three of our simpler classes and tests the resulting bundle size:

{code:javascript}
import {Schema, Field, Float32} from 'apache-arrow';

// | Bundle Size        | Compressed     
// | 202KB (207112) KB  | 45KB (46618) KB
{code}

We can help solve this with the following changes:
* Add "sideEffects": false to our ESM package.json
* Reorganize our imports to only include what's needed
* Eliminate or move some static/member methods to standalone exported functions
* Wrap the utf8 util's node Buffer detection in eval so Webpack doesn't compile in its own Buffer shim
* Removing flatbuffers namespaces from generated TS because these defeat Webpack's tree-shaking ability

Candidate functions for removal/moving to standalone functions:
* Schema.new, Schema.from, Schema.prototype.compareTo
* Field.prototype.compareTo
* Type.prototype.compareTo
* Table.new, Table.from
* Column.new
* Vector.new, Vector.from
* RecordBatchReader.from

After applying a few of the above changes to the Schema and flatbuffers files, I was able to reduce the vis.gl's import size 90%:
{code:javascript}
// Bundle Size      | Compressed
// 24KB (24942) KB  | 6KB (6154) KB
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)