You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Paul Taylor (Jira)" <ji...@apache.org> on 2021/02/03 03:42:00 UTC
[jira] [Commented] (ARROW-10255) [JS] Reorganize imports and
exports to be more friendly to ESM tree-shaking
[ https://issues.apache.org/jira/browse/ARROW-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277659#comment-17277659 ]
Paul Taylor commented on ARROW-10255:
-------------------------------------
[~bhulette] I vote no on the current PR for 3 reasons:
# Arrow releases have moved to releases major-version-revs only, so npm won't upgrade libs/people by default
# The [very minor changes|https://github.com/apache/arrow/pull/8418/files#diff-281075682d7444bc1be962b47cff16401e18f1b9bafee2b58557a3f73fb54507] we had to make to our own tests makes me think this shouldn't be a huge pain to upgrade for users (not to mention Field and Schema aren't the most common APIs to interact with directly)
# These changes are needed by [vis.gl|https://github.com/visgl] to import ArrowJS in [loaders.gl|https://github.com/visgl/loaders.gl]. Currently they're reimplementing the bits of Schema/Field/DataType they need because importing ours adds ~250k (~24k minified) to their bundle, which is over their size budget.
> [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
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)