Zod to Valibot Size Reduction

[Everduin94]

Hey there

We recently migrated our project from zod to valibot (yay 🥳). My project is a very small CLI git helper so valibot seemed ideal, as zod was representing 50% of the projects total size.

My question is, am I doing something wrong with valibot? We only noticed a 6kB decrease in size

• With ZOD: https://bundlephobia.com/package/[email protected]
• With Valibot: https://bundlephobia.com/package/[email protected]
• Packagephobia even suggests the project went up in size: https://packagephobia.com/[email protected]

Maybe it's the way these online bundle analyzer just look at package.json? Is there a more accurate way for me to determine size?

Alternatively, am I doing something wrong here? (List of imports): https://github.com/Everduin94/better-commits/blob/main/src/vali-state.ts#L1-L13

I appreciate any feedback or input, thanks! :)

[fabian-hiller]

Valibot should add less then 2 kB to your bundle. Check it here.

After compressing it with the other code in your package, the actual size that Valibot adds is even smaller. Furthermore, after we merge #502, it will be even smaller by about 20%.

[fabian-hiller]

I think your problem is that you are building your library for CommonJS only. I recommend to build your project for ESM as well and use it as the default. Check out the build step and import configuration of Valibot. Reach out if you need help.

[Everduin94]

Makes sense! I see that building with esm is way smaller.

A hiccup I'm running into.

file:///Users/erik/dev/better-commits/node_modules/valibot/dist/index.js:1761
    expects: `${wrapped.expects} | undefined`,
                        ^
TypeError: Cannot read properties of undefined (reading 'expects')
    at optional (file:///Users/erik/dev/better-commits/node_modules/valibot/dist/index.js:1761:25)

I get this exception , when I try to run my ESM build target

---

More context. I actually got this same exception when I originally switched from zod to valibot. - I fixed it by changing the import order. In this context, since it's a generated file, I can't really do that. Also, I can't imagine why import order would matter here. I don't know that I've seen anything like that before

// --> This must be imported before ./utils or fails to compile
import { BranchState, CommitState, Config } from "./vali-state";

import {
  BRANCH_ACTION_OPTIONS,
  CACHE_PROMPT,
  OPTIONAL_PROMPT,
  V_BRANCH_ACTIONS,
  V_BRANCH_CONFIG_FIELDS,
  V_BRANCH_FIELDS,
  load_setup,
} from "./utils";

[Everduin94]

Edit: I thought I had this figured out, I did not. Instead it was silently failing with a different error after I moved the imports around. :(

[Everduin94]

Sorry for stream of comments I think I have a much more solid question now.

custom behaves differently depending on when I build my program via cjs or esm.

For example. When built with cjs the val.options will never be undefined. It will use the default defined in the optional.
However, when built with esm the val.options inside of custom will return undefined and not utilize the default.

commit_type: v.transform(
    v.optional(
      v.object(
        {
          enable: v.optional(v.boolean(), true),
          initial_value: v.optional(v.string(), "feat"),
          infer_type_from_branch: v.optional(v.boolean(), true),
          append_emoji_to_label: v.optional(v.boolean(), false),
          append_emoji_to_commit: v.optional(v.boolean(), false),
          options: v.optional(
            v.array(
              v.object({
                value: v.string(),
                label: v.optional(v.string()),
                hint: v.optional(v.string()),
                emoji: v.optional(v.string([v.emoji()]), undefined),
                trailer: v.optional(v.string()),
              }),
            ),
            DEFAULT_TYPE_OPTIONS,
          ),
        },
        [
          v.custom(
            (val) => {
            // --> CJS - returns DEFAULT_TYPE_OPTIONS
           // --> ESM - returns undefined
            console.log(val.options)
            return val.options.map((v) => v.value).includes(val.initial_value) // --> ❌ Fails here
            },
            (val) => {
              const input = val.input as { initial_value: string };
              return `Type: initial_value "${input.initial_value}" must exist in options`;
            },
          ),
        ],
      ),
      {},
    ),
    (val) => {
      const options = val.options?.map((v) => ({
        ...v,
        label:
          v.emoji && val.append_emoji_to_label
            ? `${v.emoji} ${v.label}`
            : v.label,
      }));
      return { ...val, options };
    },
  ),

This is the same behavior I saw when I mentioned the context above. Changing the order of imports also caused this to happen regardless of cjs or esm. Sorry if this doesn't make a ton of sense, I am pretty confused 😅.

[Everduin94]

One more comment 😅

If I move DEFAULT_TYPE_OPTIONS from ./utils.ts, into the file that contains this schema, vali-state.ts. It works fine.

[Everduin94]

Sorry I'm a ding-dong. Circular dependency 🤦.

[fabian-hiller]

So could you solve it?