[Proposal] Become a Deno first library

[syhol]

Today, this library is developed in Node.js and configured to support Deno.
I propose that it's migrated to be developed in Deno and configured to support Node.js.

I realise this is an intimidating idea, but I believe you could have the same (if not better) output and a much better contributor experience.

Why is Deno a good fit for Valibot?

Aligned Philosophy

• Both Deno and Valibot believe in decomposing code into small modules so users can just depend on what they need
• Both Deno and Valibot care about browser/web compatibility
• Both Deno and Valibot care about strict TypeScript type safety
• Both Deno and Valibot care about developer experience

Tooling Simplicity

In order to get typescript, tests, linting, and formatting you are using 9 direct dependencies from 4+ different teams totalling 117MB. These dependencies all require a bunch of different configs:

• tsbuild.json
• prettier.config.cjs
• .prettierignore
• package.json
• vite.config.ts
• .eslintrc.cjs

Deno has all of this functionality baked into the deno binary, managed by one team. Since it uses very sensible defaults you only need very little config and it all lives inside deno.json. Pulling in the Deno packages bdd + expect can provide a more familiar testing experience for only an extra ~85KB. While dev dependency size isn't an important metric in itself, it's a good indicator of how much complexity you're depending on.

Testing Across Runtimes

Vitest does not work on Deno today, this makes it hard to run the same tests across both runtimes. If the library migrates to Deno.test and uses dnt for Node.js compatibility then dnt automatically runs the tests in the Node.js runtime with full compatibility.

Cons, Risks, and Unknowns

• Expect Compact: There is no native deno library that supports expect.any so we would need to either continue using npm:expect or refactor the tests so they don't use comparable.ts
• Deno as a barrier to contribution: More potential contributors will have a Node.js setup. It doesn't take long to install Deno and the vs-code extension, but it might deter some people.
• No deno bundler: Deno doesn't have any built-in bundle tooling and dnt doesn't minify, so either keep tsup or look for an alternative.
• tsup + dnt compact: It looks like dnt (the primary deno to npm converter) restructures the output a bit, it might need a bit of tweaking to keep backwards compact. Tsup could then run on the Node.js esm output from dnt.

End note

No pressure on any of this. I think it's a cool opportunity but I can see you have a lot on. I've thrown together a PoC in my fork: syhol#2 and I've got it building but it needs tsup integration and tidy ups.

[fabian-hiller]

Thank you for all the details. It is interesting, I was thinking about migrating to Bun but I was not sure if that is a bad idea for all Windows contributors. I'll keep this issue in mind, but don't expect a quick reaction. I think it a good way to get feedback and discuss about it here with more people.

[notramo]

I think it's a bad idea to make Valibot an <any JS runtime>-first library. Instead, modernisation should be done in a runtime-agnostic way.

Bun is also a viable modern runtime, and Node also gained native TS import support in latest versions. Neither Bun nor Deno support Vitest. One can think they do it intentionally to force users to use their built-in test libraries, which locks the project into their ecosystem.

I recommend replacing Prettier with Biome, which is a runtime-agnostic eslint-compatible linter, prettier-compatible formatter and it also has an import sorter. Plus, it's a lot faster than prettier/eslint, because it's written in Rust. It also provides fast LSP-based editor integration.

[syhol]

I think it's a bad idea to make Valibot an -first library

When I wrote this issue Node didn't properly support ESM and Bun didn't recommend using file extensions with ESM. So at the time Deno seemed to most align with what Fabian was doing with modular design and browser http imports.

Since then Bun/Node/Deno have converged more and more, and browser http imports seem to have gone out of fashion before they ever took off. This Deno proposal isn't as relevant today.

Neither Bun nor Deno support Vitest

bun run test passes 100% and deno run test passes 95% with just one issue that causes about 5% of the tests to fail. So not perfect but it is technically supported and they are fixing issues as they find them.

One can think they do it intentionally to force users to use their built-in test libraries, which locks the project into their ecosystem.

I doubt it. vitest and jest do/did some pretty gnarly stuff depending on some very specific nodejs systems and it's taken a long time for deno/bun to support them. Deno 2.0 and JSR has thrown out so much of its original USP because they really want drop-in compatibility with the node ecosystem. The built-in testing exists for the "it just works" selling point, especially because jest and typescript were so annoying to get working together.

I recommend replacing Prettier with Biome

Yeah, if you won't move to Deno I would definitely agree. Biome was only 1 month old when I wrote this issue 😁

[fabian-hiller]

Hey everyone, thanks for your feedback. At the moment the library source code is more important than our development setup, but I will keep an eye on the ecosystem and improve our setup from time to time. I have started using Deno for scripting in other projects and am curious to see where things go at VoidZero.