Bloating with esbuild bundled output

[samratarmas]

Hi Colin!

Awesome project, I came across this issue as referred by the following:

Originally posted by @gustavopch in #294 (comment)

The thread confirms your intention of having tree-shakable esm code, and it is marked as resolved and closed. However, esbuild currently bundles all of Zod into your output if you import a simple zod schema.

Steps to replicate:

• Creating a simple ts project that uses esbuild with bundled output enabled.
• Create a simple zod schema:

import {z} from "zod" const testSchema = z.string().min(10)

• Validate some random string using the test schema
• Build the project with esbuild using bundled output (also bundling external node_modules, so would be zod module in our case. This is currently how edge functions such as wrangler cli for cloudflare workers bundle ts, and the bundled code is several thousand lines of unused js from Zod in an edge environment supposed to be small and lightweight)

Another similar comment in thread:
Originally posted by @ekwoka in #294 (comment)

Is treeshaking working as expected? Looking forward to hearing from you,
Cheers!

[ekwoka]

I think a better example would be importing just string.

Importing z is the whole thing even if the package were more treeshakable, since treeshaking methods and properties off of objects is generally much harder.

[gustavopch]

Tree-shaking doesn't work because Zod relies on method chaining. For tree-shaking to work, it should expose individual functions like https://github.com/ianstormtaylor/superstruct (s.nullable(s.string())).

❌ Not tree-shakeable:

import { z } from 'zod'
z.string().nullable()

✅ Tree-shakeable:

import { nullable, string } from 'zod'
nullable(string())

✅ Also tree-shakeable:

import * as z from 'zod'
z.nullable(z.string())

It's arguably uglier because of the inverted order as JS doesn't have a pipeline operator yet, but surely a good trade-off to reduce KBs on the client.

It's also possible to do as Firebase did when they released their Modular API and create a compat layer that exposes a fluent interface that works as a facade (in which case you lose tree-shakeability), e.g.:

import { z } from 'zod/compat'
z.string().nullable()

[ekwoka]

It could be nice if at least the basic types string number etc were treeshakable, and maybe have some of the "special" ones on their own like email at the top level instead of string().email() etc.

Are you sue importing z is still tree shakable in the common major bundlers? Mainly Rollup and ESBuild?

[gustavopch]

@ekwoka Are you asking about import * as z from 'zod'? If so, yes, it's tree-shakeable. It's different from import { z } from 'zod' because the latter imports an object, and objects are always imported as a whole.

Press "Bundle" and look how multiply is not in the output when using a namespace import: https://esbuild.egoist.dev/#W1siaW5kZXgudHMiLHsiY29udGVudCI6ImltcG9ydCAqIGFzIG1hdGggZnJvbSAnLi9tYXRoJ1xuXG5tYXRoLnN1bSgxLDIpIn1dLFsiZXNidWlsZC5jb25maWcuanNvbiIseyJjb250ZW50Ijoie1xuICBcImZvcm1hdFwiOiBcImNqc1wiLFxuICBcImNkblVybFwiOiBcImh0dHBzOi8vY2RuLnNreXBhY2suZGV2XCJcbn0ifV0sWyJtYXRoLnRzIix7ImNvbnRlbnQiOiJleHBvcnQgY29uc3Qgc3VtID0gKGE6IG51bWJlciwgYjogbnVtYmVyKSA9PiBhICsgYlxuXG5leHBvcnQgY29uc3QgbXVsdGlwbHkgPSAoYTogbnVtYmVyLCBiOiBudW1iZXIpID0+IGEgKiBiIn1dXQ==

[ekwoka]

Fantastic 😍

[gustavopch]

It's arguably uglier because of the inverted order as JS doesn't have a pipeline operator yet, but surely a good trade-off to reduce KBs on the client.

The newly released library Valibot has a clever approach to keep the order of the functions and still have maximum tree-shakeability: string([email(), endsWith("@example.com")]).

[cafesanu]

Tree-shaking doesn't work because Zod relies on method chaining. For tree-shaking to work, it should expose individual functions like https://github.com/ianstormtaylor/superstruct (s.nullable(s.string())).

❌ Not tree-shakeable:

import { z } from 'zod'
z.string().nullable()

✅ Tree-shakeable:

import { nullable, string } from 'zod'
nullable(string())

✅ Also tree-shakeable:

import * as z from 'zod'
z.nullable(z.string())

It's arguably uglier because of the inverted order as JS doesn't have a pipeline operator yet, but surely a good trade-off to reduce KBs on the client.

It's also possible to do as Firebase did when they released their Modular API and create a compat layer that exposes a fluent interface that works as a facade (in which case you lose tree-shakeability), e.g.:

import { z } from 'zod/compat'
z.string().nullable()

Hi @gustavopch, do you mind expanding on why import * as z from 'zod' is tree shakable? We are currently trying to decide our best option for importing, and are unsure which one is actually the best way

[gustavopch]

@cafesanu The syntax is compatible with tree-shaking, but it depends on Zod using named exports for each function, which is not the case, so you won't be able to tree-shake Zod, no matter how you import it.

[ivands]

I would love to see a functional version of Zod, making it tree-shakable.
Method chaining is nice, but extremely small bundle sizes are nicer.
Especially for my serverless use case.

[dreamorosi]

Any chance that this discussion can be picked up again? This is really an important topic imo

[ivands]

If anyone is interested.
I ended up using Valibot.
It's a really good alternative to Zod that is completely tree-shakable.
https://github.com/fabian-hiller/valibot

[matthew-dean]

@ivands 👍 to Valibot. Valibot was the API I expected Zod to have considering how recently it was built, in order to be compatible with modern bundlers. It looks great so far!