Large bundle sizes

[coryvirok]

When I import using import { Chart, Axis, ... } form 'layerchart' I'm seeing many additional packages make their way into the build files.

repro: https://stackblitz.com/edit/sveltejs-kit-template-default-skoueh8c?file=.svelte-kit%2Foutput%2Fserver%2Fentries%2Fpages%2F_page.svelte.js

E.g. For my SvelteKit project, when I run npm run build for an app with the following page, you can see the additional imports included in the build results, which I've included the imports for below.

<!-- +page.svelte -->
<script>
  import '../app.css'
  import { scaleBand, scaleOrdinal, scaleTime } from 'd3-scale';

  import { Chart, Layer, Axis, Bars } from 'layerchart'

  import { data } from './data'
	
</script>

<div class="h-[300px] p-4 border rounded-sm">
  <Chart
    {data}
    x="date"
    xScale={scaleBand().padding(0.4)}
    y="value"
    yDomain={[0, null]}
    yNice={4}
    padding={{ left: 16, bottom: 24 }}
  >
    <Layer type="svg">
      <Axis placement="left" grid rule />
      <Axis placement="bottom" rule />
      <Bars strokeWidth={1} class="fill-primary" />
    </Layer>
  </Chart>
</div>

// Top of build file: .svelte-kit/output/server/entries/pages/_page.svelte.js

import "clsx";
import { i as is_array, k as get_prototype_of, o as object_prototype, n as noop, l as deferred, m as hasContext, g as getContext, s as setContext, p as push, q as spread_attributes, t as clsx, u as bind_props, f as pop, v as attr_class, h as escape_html, w as attr, x as stringify, y as props_id, z as attr_style, A as spread_props, B as copy_payload, E as assign_payload, F as ensure_array_like } from "../../chunks/index.js";
import { scaleLinear, scaleSqrt, scaleOrdinal, scaleBand } from "d3-scale";
import { Logger, format, localPoint, sortFunc, unique, isLiteralObject, Duration, DateToken, PeriodType, greatestAbs } from "@layerstack/utils";
import { cls } from "@layerstack/tailwind";
import { get } from "lodash-es";
import { rgb } from "d3-color";
import memoize from "memoize";
import { InternSet, max, min, bisector, extent } from "d3-array";
import { t as state, u as render_effect, n as set, o as get$1 } from "../../chunks/runtime.js";
import { quadtree } from "d3-quadtree";
import { curveLinearClosed, lineRadial, line, pointRadial, arc } from "d3-shape";
import { interpolatePath } from "d3-interpolate-path";
import { objectId } from "@layerstack/utils/object";
import { Delaunay } from "d3-delaunay";
import { geoVoronoi } from "d3-geo-voronoi";
import { geoPath, geoTransform } from "d3-geo";
import { path } from "d3-path";
import { timeTicks, timeYear, timeDay, timeHour, timeMinute, timeSecond, timeMillisecond } from "d3-time";
import "@dagrejs/dagre";
import "d3-tile";
import "d3-sankey";

System details:

  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 20.19.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    d3-scale: ^4.0.2 => 4.0.2 
    layerchart: ^2.0.0-next.27 => 2.0.0-next.33 
    svelte: ^5.25.0 => 5.36.13 

[coryvirok]

I should note - this is important even though the bundle size I'm worried about is in the server build, because I'm running into out of memory errors in GitHub actions workflow where I'm building my app. Since this is a major offender, it's important to fix, IMO.

[techniq]

Hey @coryvirok 👋

I've been making progress reducing the install and bundle size of LayerChart, but definitely have more opportunity to cut it down. Looks like you are running the latest @next release, which is good.

Currently I use node-modules.dev to help identify install size opportunity, and rollup-plugin-visualizer as well as shadcn-svelte's rollup visualizer to identify bundle size opportunity.

Running pnpm build and pnpm preview in packages/layerchart and then going to http://localhost:4173/stats will show you the bundle of the docs ATM. I need to create more isolated/simple examples which would also make identifying issues, as the full docs is hard to comb through.

Here are some of the areas I've identified to help reduce install and bundle sizes:

• (DONE) Drop usage of date-fns for lighter LayerStack / d3-time funcs (details)
• Drop/replace lodash usage in LayerStack and LayerChart
  • Progress has been made in both repos but more replacement implementations need written
• Split components by context to reduce bundle size #555
• Move some components to sub directories/packages to reduce bundle size #617
• Support importing individual components (to reduce bundle size) #618
• Setup automated bundle analysis #758

TBH I'm surprised you're running into Github action workflow issues regarding LayerChart as I use actions extensively on many projects (including the LayerChart docs, Github Analysis, Strava Analysis, and many work projects), and have never encountered an issue myself. It's also used on a lot of other projects, including shadcn-svelte, and haven't seen a Github actions failure related to LayerChart thus far.

Have you tried running rollup-plugin-visualizer (or similar) within your project to see if there are other large packages? If you find any specific items I can take a look (also need to start knocking out some of the aforementioned items).

[coryvirok]

Thanks for the reply. I'm not sure what exactly is causing the OOM in GH actions, so I'm just looking to decrease build sizes across the board. Here are some other folks who have run into the same OOM issue. I'm not saying this is a Layerchart bug. Just that Layerchart is producing some larger than necessary files.

Your proposed ways to reduce size LGTM. Thanks for taking a look and for Layerchart! Also, congrats on getting shadcn-svelte to use Layerchart for his lib! Great combo!