tools VS io-ts

Biome is a fork of Rome, which was originally an ambitious tool written in Rust but abandoned in October 2023. It includes both a linter and a formatter, putting an end to the time-consuming difficulties associated with reconciling ESLint and Prettier rules.

When I saw the release of bun six months ago, I was not that hyped as I saw a tool that had similar ambitions, Rome, and dissapointed many. But it was different this time. It really is a drop in replacement for Node.js so you can start using it by replacing the npm and node commands in your package.json file. The main feature that captured my interest was the ability to use require and import statemtents in the same file. This allows you to keep using CommonJS modules and use import statemtents for any new modules that drop support for it. The only catch I could find so far is that if you decide to mix import and require statements, you cannot use module.exports but instead use export statement. I did exactly that and now I have a fully functional backend with admin panel that won't make your head scratch fighting with CommonJS and ESModules.

Once you build a simple Vite backend integration, try not to complicate Vite's configuration unless you absolutely must. Vite has become one of the most popular bundlers in the frontend space, but it wasn't the first and it certainly won't be the last. In my 7 years of building for the web, I've used Grunt, Gulp, Webpack, esbuild, and Parcel. Snowpack and Rome came-and-went before I ever had a chance to try them. Bun is vying for the spot of The New Hotness in bundling, Rome has been forked into Biome, and Vercel is building a Rust-based Webpack alternative.

It definitely existed by the time rome_console/biome_console was created! The crate was created 2 years ago[1] and miette was released more than 2 years ago[2]. By the time rome_console was created miette was on v4, so presumably somewhat mature.

[1]: https://github.com/rome/tools/commits/main/crates/rome_conso...

[2]: https://crates.io/crates/miette/versions

Biome formats and lints your JavaScript and TypeScript code in a fraction of a second. Biome is the community successor of Rome Tools [0].

As part of this announcement, we have released the first stable version of Biome [1]. Join us on our Discord [2] and support us via our open collective [3].

I am one of the main maintainers of Biome. I will be happy to answer any questions :)

[0] https://github.com/rome/tools

I have no idea how true this is, but the source of the claim seems to come from here:

https://github.com/rome/tools/discussions/4302

"But in short, the company Rome Tools ran out of funding, so the core team of last year are no longer working on the project."

For now, Rome implements most of the ESLint recommended rules (including TypeScript ESLint) and some additional rules that are enabled by default. In the future, you can expect a recommended preset that is a superset of the ESLint recommended preset. So if you're not heavily customising ESLint, you should be able to use Rome.

Otherwise, most of the rules are not fine-tunable in the way that ESLint is. Rome tries to provide the experience that Prettier provided in the formatting tool: good defaults for a near-zero configuration experience. It tries to adopt the conventions of the JS/TS community. Still, some configuration is provided when the community is divided on some opinions (e.g. space vs. tab indentation, semicolons or as-needed semicolons, ...).

There is an open issue [1] for listing equivalent rules between ESLint and Rome. Expect more documentation in the future, and maybe a migration tool.

If I had been one of the founders of Rome, I could have pushed for more compatibility with ESLint. In particular, using the same naming conventions and thus the same names for most rules, and recognising ESLint ignore comments.

[1] https://github.com/rome/tools/issues/3892

Today we are going to talk about Rome. According to their github page

I must say, although it doesn't (of course) have anywhere near the configuration or plugin-capability of eslint, I've found Rome impressive so far. I have access to a range of PCs and the performance boost of a compiled binary makes a pretty big difference on a large repo on a slower machine.

Fast compilation seems very appealing. It is one of the main reason why I am interested into Go and Zig.

I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. The compilation and IDE experience is frustrating. Compilation is slow. I am afraid that this is rooted to the inherent complexity of Rust.

[1] https://github.com/rome/tools

[2] https://github.com/denoland/deno_lint

Qué rico. Si tenés chance meté un proceso de code review fuerte, y para el tema de I/O probá a usar https://github.com/Effect-TS/schema ó https://github.com/gcanti/io-ts que les da una solución obvia al tema de "tipos para lo que devuelva el backend", aunque es en realidad mucho más capaz que eso.

My fave is still io-ts (https://github.com/gcanti/io-ts/blob/master/docs/index.md) as I find it more flexible than zod at the ingress. The author is also working on the Effect ecosystem which also looks interesting.

I’ve been using io-ts for this and been very happy with it. [1] It’s similar to Swift’s Coding protocol in case you’re familiar.

[1] https://gcanti.github.io/io-ts/

Yeah, there are a few new concepts and it's not the easiest to pick up right away. The best introduction is here on the main documentation page.

We use https://github.com/gcanti/io-ts/blob/master/Decoder.md which has a very similar interface. It can even be used to mutate the data using https://github.com/gcanti/io-ts/blob/master/Decoder.md#the-parse-combinator.

A good way to significantly improve the reliability of your app is via improving type-safety by moving away from using any to unknown. One relevant example could be when you type your backend responses and when stringifying JSON to using unknown combined with some sort of runtime type checking. It can be done either by using built-in functionality like type guards or using an external library like io-ts, zod or yup.

Usage of TypeBox is similar with io-ts and zod, but it is much powerful and faster than them. Also, TypeBox can generate JSON schema very easily. Therefore, if you're looking for a validator library for new project and not suffering from legacy codes, I think TypeBox would be much better choice than io-ts and zod. TypeBox can totally replace them.

This check can be done with different libraries like: io-ts, typebox, or zod. These libraries allow you to create objects that represent your typescript definitions. Then, these objects can be used at runtime to validate the received data, in addition, you can also convert this object to a Typescript definition to have all the benefits of using typescript. These objects can be called schema validations because they are responsible for the data validation.