Modern web development requires an ever-growing collection of tools, including formatters, linters, bundlers, and plugins. Each tool typically has its own configurations, dependencies, and performance cost. As applications grow more complex, the overhead of maintaining this tool chain becomes a real burden. Biome is an open-source tool chain for web projects that brings formatting and linting together in a single, fast, opinionated tool. It's built and rust and is designed to be a drop-in replacement for prettier and ES-Lint, with sensible defaults, minimal configuration, and consistent behavior across the CLI and editor environments. Biome also introduces a module graph that enables cross-file analysis and type-aware
lint rules that don't require the TypeScript compiler. Amano Elastaba, known as Emma, is a senior systems engineer at CloudFlare, a lead at Astro, and the creator and lead maintainer of Biome. In this episode, Emma joins Josh Goldberg to discuss the history of Biome, how linters and formatters work under the hood, what makes Biome's architecture fundamentally different from the tools it replaces, and what's coming next for the project and its community. This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES-Lint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of the O'Reilly
Learning TypeScript book, a Microsoft MVP for developer technologies, and a co-founder of Squiggle Comp, a conference for excellent web developer tooling. Find Josh on BlueSky, Flostodon, and .com as Joshua K Goldberg. As a majority of developers out there were like, I want to develop video games, so that's essentially why I got into coding. Things didn't plan as I thought they were, and I went to university where they were supposed to teach a game design, but in the year where I was supposed to join that class, there was no professor. So I had to choose another class, and eventually I haven't done anything
around video games, so I ended up doing PHP, Postgres, and all the stuff that Web dev was at that time. That's how I started, so that it was PHP developer, jQuery, and so on until React and all the cool kids that we have now. Do you have any emotions that come to mind when you think about developing front-end, full stack apps and PHP and jQuery? Yes, because I see a lot of partners that I used to use back in the day coming up, like SSR, before it was anything, like React developers, and it was all about spas everywhere, so everyone was developing single page applications, and that SSR came back because that's how you used to do things in PHP. So I mean, there's nothing new here, we are just doing things as they were just using JavaScript instead of PHP, C-sharp, or Java, you know, that time that's what we had. So it's kind of weird because like we are not inventing anything,
we just we are not fermenting the wheel. There's nothing exciting, you know, it's just the same patterns using different tools, different libraries. I like the tools that we have now simplify the process. Back in the day when I wanted to do spas or islands, for example, it was a mess now. We know how to do these kind of things, the libraries allow us to do that, so it's like, thank God, now that we can do things very quickly. It's lovely that we've learned how to do
the same proper techniques, both a lot of cleaners and tacks now. We've been asked to kind of a transition for you. You started off as a sort of standard developer working on apps, PHP, jQuery, and so on, but at some point you transitioned to dev tooling, and one of the earliest projects that you were associated with in that space that got a lot of interesting news was Rome. Can you tell us about how that came to me and what that is? Yeah, so Rome, Rome tools was a project that was supposed to be like only one tool for all your web projects, so I had informative, LinkedIn, bundling, testing, everything in one single application or binary or whatever. And I really
liked it. The mission behind it. In the past, I always struggled to maintain a lot of these dev libraries, such as formators, linters, bundlers, plugins, and Rome was like a breath of a share, and I was looking for an open source project to contribute to it. So yeah, I mean, let's do it. That's how I joined the mission. Rome at that time was in TypeScript, and eventually Rome got some
funding. They opened the company and they joined as an employee of the tool. That's essentially how I got there. But like my passion to open source came before us, Rome. I was involved in the webpack before that. I was part of the CLI team. And why? Because like I fought with webpack a lot of times
in my working experience with all the companies where it worked, and they became a kind of an expert. I was also on Stack Overflow answering questions and things like that. So I wanted to increase my knowledge around webpack and that's how you do it. You're just going to open source and you learn stuff from the actual creators. How did you make that jump from learning about webpack to contributing back to it or to helping others? That seems like kind of a scary cliff for a lot of
people at a gap in difficulty levels. Yeah, it is scary. But at the end, you just have to do it. It's like a leap of faith. So you can't understand that you can't know everything. So you have to
make the piece with it and just say, I don't know this, I don't know that. But I have experience with this thing. So maybe that's your solution. Maybe this is your other solution. So once you understand that you can't know anything and you have to accept that others might have the answer, it just gets easy. So eventually you just do your stuff that you want to do and you try to learn
what you want. And for you that's been simplifying those complex text text, you've mentioned it's something that leads you to write it. Yes, yes, exactly. Before tooling, I was in front-end and it's a couple of different words. Like tooling requires a lot of different knowledge from front-end.
But there are some similarities. There are some lessons that you can take from front-end and where there's accessibility error endlings and fighting with browsers, fighting with things that don't work in a lot of contexts. Take that into your tooling and for example, error endling, it's the same. Like you have your user that does a mistake, you have to handle it. You have your back-end that does something funky, you have to handle it. Same for tooling. You always have your user that you put
something via CLI, for example, and you have to essentially provide some decent feedback. So it's a different context, but at the end it's a product. You have your users and you have to provide something good that they like. So it's not that scary and in programming you always have the same problems more or less, different contexts, but at the end it's just about data. You get some data, you have to parse them and then do something with it. And if it doesn't work, you just send in a
good feedback. If it does, you send the feedback that they use it. Functional programmers may be pleased to hear that, but everything ends up turning into a function that returns one of two types. Let's talk about that doing something with it. Because you worked on several projects now that do something with code that builds it. So at the very barest before we go into the details,
what is a builder or what is a bundler? Well, a bundler, what it is. Well, I just said like a bundle is a linker. So it's like taking different files and just create something that is linked all together in modern programming. Now the web ecosystem, we have a bundler that has to take a lot of JavaScript files scattered in your application and dependencies and eventually creating something that it's pleasable to use in the browser for you as a developer, but especially for users, your end users. So you have to ship something that doesn't break. You have to ship something that
doesn't takes a lot to download, for example. So you can't ship all like a file of your all dependencies. Otherwise, it's like mags or mags of JavaScript that your user is to download. And I mean, I've tested also with a lot of different things like HTML, CSS, SaaS, less TypeScript, CoffeeScript, Wasm now, and a lot of stuff. So a bundler nowadays is actually, for my point of view, one of the most difficult and rewarding software that you can create or contribute to because there's a lot of the care. And I think it's like it's a
you learn a lot if you anyone wants to work on it because there's a lot of, you know, also so smart. So yeah, there's a lot going on there. Let's say that I have just the most barest of applications that uses import and exports. I got an HTML page, a JavaScript file that imports from a couple of modules, maybe another JavaScript file that imports that one calls it. And I want to turn that into some dot com website. And I'm going to use a tool to do that. First of all,
do I need to use a tool? What situations can I, if any, get away without that? Well, you could use a tool, but also you can't. It depends on your taste like back in the day with PHP and these kinds of things like you didn't need to, you just have your PHP file. It means your JavaScript and everything. So you've got everything up to the box. Nothing's got more complex. Our users need
more. The browser has more capabilities. Like we are recording our session on a browser, something that we couldn't do 10 years or 15 years ago. So capabilities increased. We have more tools at our disposal. So even the applications got complex based on what we want to ship. So eventually,
you want to use a tool. It simplifies a lot of boilerplate like setting up the page or deems or even JavaScript in interactions and things like that. You could do it yourself, but there's a lot of going on nowadays. So you don't want to do it and you want to focus on your app. You don't want to focus on the boilerplate. So yes, nowadays, you should use a tool that simplifies
all the basics. And so you can focus on creating whatever you want on the browser or even electron where you have your native app. So you see the capabilities that we have and less possibilities. All right. You've convinced me for my HTML and a couple of JavaScript files page, I know I will get more complicated. So I will use a builder or a bumper. How does that actually work? How do we
go from that source codes, what across different JavaScript files to something that gets run by users with all those optimizations you talked about? That's a really interesting question. I don't have a clear answer, but as a developer of some tools that do the kind of things such as Astro, how does it work? So you have a concept of pages, which are essentially your entry points where your user lands. And from there, you essentially start building your three of dependencies, which are styles, CSS files, components, JavaScript files, anything that your page requires.
And that's how your bundle works. So you have your entry points where your user needs to interact, call them pages. So in most of the cases are synonymous entry points or pages. And there your bundle creates a tree of dependencies of assets, essentially what it needs to ship in order to render and make the page functional. Of course, there are a lot of challenges like understanding the CSS files. Now these things got more complex because styles in some applications
are shipped together with some components. So they are like a timing, like for instance, views belt and Astro, they have the concept of components, single file components. And each file component can contain a piece of JavaScript, contain a piece of HTML and a piece of styling. So when you have multiple components that are inside the tree, you also need to understand the order of how this style needs to be bundled together in order to actually not mangle the end result. Like you could have your button that is imported in the middle of the tree or in the end of the tree, and then you have to decide, okay, now what's the order? And that's what the bundle does. So
it's responsible to tackle these kind of problems for you. So you don't need to fight them. And of course, bugs can be there, but that's what the bundle does for you. And same for JavaScript. So you have a lot of scripts important in your tree. You have to make sure that they are imported and
executed in order. So eventually your button reacts to a form submit or it reacts to an error in your farm without breaking other scripts. So that's I think like the bundler works. It's interesting the way that you describe the assets because very little of anything in your explanation is specific to JavaScript files. So let's say that we have a new kind of asset. Let's
say I want to import some dot web image and then use it as a source string in my file. In the system, does that mean that I can have sort of arbitrary extensibility plugins for different sorts of assets? Yeah, technically, yes. If the bundle allows you to do so, but essentially, yeah, a bundler needs to work like in a very abstract way. But then yes, it has a specialized section where it needs to understand what is actually processing. So CSS files, images,
which have different extensions or different kind of encoding and things like that. We have WASM, which also requires its own instantiation and other things. We have fonts, for example, that's another asset that needs to be treated in a certain way. So yeah, I mean, nowadays, we are creating bundlers that has to be designed in a generic way and extensible. So users can extend the bundler for their needs. But not everyone needs to deal with Web images or Aviv
or videos, for example, there's also this kind of asset. So in the while now, we're creating, since Webpack area or roll up, we are creating bundlers that are generic and users can extend it. So we are setting on a plugin system where users can essentially do whatever they want with the bundler that users can do whatever they want, yields a lot of power for users. But a lot of long lasting web developers may remember that power comes with a cost. Let's talk about two of those costs here, performance and configurability or ease of use. There are horror stories out there
of multi-thousand line webpack and figs that are slow. What would your response to that be? So my, let's go to believe, for opinions on plugins, I've shifted a lot recently, especially now that I'm dealing with bioin, which is built with a native language and astro, which is completely different, uses plugins. So as you said, there's a cost and I think people shouldn't pay that cost. Like you have a lot of extensibility, but yes, as accurate, that's nice. You do your project
weekend. You can create your plugin and you have a sense of power. Like you're doing something great because you're creating stuff. But then there's the other side of the coin, which is you are at work, you are responsible for maintaining the product of your employer. And that's the cost you pay.
You have a lot of plugins, you have a lot of extension iterations that you have to deal with and you have a cost on your application. Sure, then the bundler somehow has to be responsible of it and reduce the performance and make it faster. But at a certain point, I think it's not a responsibility of the bundle of the tool, the plugin system anymore. It's responsibility of the maintainers of the plugin. It eventually will pace the cost of the users. So I'm coming to a
realization that we need the plugin systems just for certain things. Other things shouldn't be extended too much, but shouldn't be baked into the tool. So I can do it correctly. I can monitor the performance. But we can't give to our users all these integrations and plugins. And eventually,
the performance of the tool, the greats. And you ended up with Webpack that takes 30 minutes to bundle the application. So I don't know. We're trying to solve this problem. We have rollup. And now we
have rolldown that wants to fix it by using a different language or maybe a different architecture. But I think it's not going to solve everything. Because like an application is going to be more powerful, demanding and bigger. Because that's how the technology works. So we're going to see maybe in three, four years, five years, we're going to see again the same problems. And we're
going to try to solve them the same way. So a counterization, now maybe we have to do something different. So that's why configurations should be static. It should be dynamic. Like they should be predictable. In fact, I know ESLint paid this cost. And that's when V9 shifted their configuration
to be flat. So like it's easily debuggable. Eventually, they couldn't understand like which plugin was making a mess. Because it was all a recursion. Like it was difficult to debug. And so they
came to the realization we have to do something. They broke the ecosystem. But I think it was something that had to be done. Because as an open source maintainer, I understand where they were coming from and why they did it. Of course, a lot of users were not happy. But I mean, they made a mistake.
They had to fix it. Some users were not happy. But in the long run, I think it's going to pay off. How do you know or how are you able to tell where that balance needs to be drawn between power for users and comprehensive built-ins? I don't have an answer for that, to be honest.
It's very difficult to draw a line there. I think it's also a matter of trying an error. Like, okay, you can be a lot very extensible. So to be honest, I don't know. I really don't know. A plugin
system allows you to do everything. But if you give it too much, you end up breaking stuff. You end up that you can do a lot of optimizations that you could do if your plugin system was more like tight or as less feature. To give you an example, like, ESLint is a great plugin system. And we have plugins everywhere. But it comes at the cost where they can't innovate now. The force of ESLint
comes from its plugin system. But now they can't innovate. They can't try new things because otherwise, all these plugins, they could break. They could degrade without knowing. So that's kind of the line.
Like, you should try to give enough power to please your developers and users, but not as much so that you can't innovate. Like, you are a programmer. So as a programmer, you also want to look for new things, try new things because that's, I think, one of our passions. And if you can't try new things, what's the point? Like, at the end, it's just doing maintenance and I don't know, it gets boring. So
maybe that's why you ended up with creating new projects and trying new things. Yeah, there's a natural cycle where once a project gets successful, that bogs it down. I want to talk a little bit about one of the major new things that a lot of projects, including Rome and Bio and Astro are, which is native speed code. You led the conversion from Rome in TypeScript to Rome in Rust. First of all, why Rust? For those who haven't heard this probably, why are so many projects
switching to specifically Rust or at least native in general? Why Rust? So I think like there are two main reasons for maybe three. Let's list them, then we come down. So first one, it's a really strict language. So when you have a dependency, there's a less
risk to break it. So like, it's so tight, the system that even like when you have a major, you have less breaking changes. Or if you have them, you catch them straight away at compile time. So it gives you the safety of having a lot of dependencies, but at least they break less often as it could happen in TypeScript or JavaScript. So you have less maintenance burden for your tolling.
Second was essentially speed. Like Rome, when it was in TypeScript, was actually great, but it suffered from a lot of memory consumption. So at that time, Rome was able to cook to bundle itself. So it was a binary could bundle itself. And what was doing that was considering a lot of memory, like eight gigs of memory. It wasn't sustainable. It felt like it reached the limit
of Node.js. So that's when we decided, okay, maybe we have to go somewhere else. You can try to do a lot of optimizations. But if you can't leverage the actual memory, like, yes, JavaScript has some tolling for the collection, but it's very, very limited. Rust as a native language allows you to manage your memory with more than JavaScript. And third point is how easy is to integrate with WASM. So like,
Rust as a native bindings using the WASM, BIND-JUN, great. So it's very easy to have your Rust code and party into WASM. So then it can be shipped into browsers, other languages that are able to interpret it WASM and execute it. That's really great for like a playground and things like that. So I think that's one of the reasons, because like, sure, the language is very typed, but even actually typed in a different way. So it wasn't the problem. And Rust has gained a lot of traction
recently for their memory safety. So you don't need to deal directly with memory like C or C++ or other similar languages, because Rustic does it for you using their borrow checker. So it takes a while to get used to, but it's the language that does it for you. So you don't need to take care about that part, so you can focus on your application. That sounds great. Let's talk a little bit about the RON was around the 2021-2022 era. How did we
get from RON to BION? What is the difference between those two projects? Yeah, so for a year and a half, we were good at RON. We were doing great. But eventually, the company behind it went under, so they couldn't get any more money. So eventually, they had to close. The
thing is, I liked the project. I joined the Open Source project before getting hired, and they wanted to continue it. So even after I left the company and they joined the other company, I continued to contribute to RON. Other people joined us. So I wasn't the only one anymore. So
eventually, we had a team of volunteers and we shipped, we continued shipping. Eventually, I really wanted to change the face of the project, but it always requires a lot of work, like logo, names, website domains. So you don't want to do that. It's really annoying. Eventually, we had to do it because the NPM tokens expired, so we couldn't actually ship and publish new versions on NPM anymore. So we were actually forced to do the move.
And why BION? So like James, which was a CTO at RON at that time, had his idea in case we wanted to change RON to call it the second RON. So second RON, BION, that was the idea. So I asked him, can I use it? Are you okay with that? Yeah, sure, go ahead. And eventually, so RON fell
December and in August of the next year, we announced BION as the new RON. I would say the mission changes slightly because we are not focusing on the BUNDER, for example, because we have less resources. We don't have people dedicated to the project, so we are now focusing on Formatter Linked, because that's what we had there. So instead of going horizontally, we went vertically, so we shipped more features into the Linter and the Formatter. So more languages, but still more like win-tros, formatting capabilities, but we are not focusing the moment on the BUNDER, or the testing suite, stuff like that. So I think we're happy with that. We're doing still
great things. So yeah, let's talk about those great things. Most users I've talked to are not extremely familiar with formatting and linting as concerns. They know that they clean up the codebase. Maybe they know that linting does more logic formatting more, well, formatting web space.
What does BioDo for users around formatting in Linter? So first of all, it creates like, it wants to ship a different developer experience compared to the tools that we have. So the better messages, something that you can actually action, you have your error and buy and tell you, okay, that's how you should do it, or you shouldn't do it. So some users yesterday, this means that it's like a nice to have. So what we're trying to do is also to teach people how to do stuff.
Like we ship this lint rule that targets the dot-reduce function of JavaScript and says to not use the spread operator when you return the accumulator. And the lint rule, as you don't do it, because it's a performance problem. And I've seen people that didn't know that. And once they know the rule, they learn something. So that's one of the missions. Like we have an inter that teaches you something.
Because as I told you before, not everyone knows everything. So if we get the chance to teach you something, I think we did good. So we're spreading the knowledge. So that's why our int rules have to have a really high standard. They have to tell you why it's an error. Because
if you're not able to tell why an error exists, then it's not an error. It's a moot point. And then like a formatting, he wants to just provide a faster experience compared to the tools that we had at that time. Like I know that users in the past were kind of unsatisfied with pre-tears performance, which was at that time the only widespread formatting in the JavaScript world and the web world. So with BioM, we provide a very similar formatting, but at least it's faster, especially in CIs and things like that. But we also like want to provide an experience that is titled to other tools. Like
BioM knows you're getting your files, for example. So you just hook into them and it doesn't format the files that I ignore and get. You can also integrate with your editor config, for example. So you have your editor and config. So you don't need to maintain the bioM config. You just use what you already
have. So it's not just about linking in formatting, but we also embrace the other tools so that BioM gets to know what you're using. And you learn from them. We're doing the same with spelled, view, astro, CSS modules. They win too. So it seems like a web dev is quite vast. We don't
want to limit ourselves to just one tool, but we think we should actually embrace a lot of them. So users get to know them and you learn something that you might not do. You've touched on one of the really lovely parts of using BioM, which is, as you said, it's all in there. You can run the format, the lint, just from one command. How much simpler is it in your experience to configure BioM compared to how things were configured, say five years ago? So I think it's actually really good and fast
because you don't lose a lot of time. I still remember when I used to set up ESLint and pre-tier years ago. And it got easier, but like the fact that you have to install three or four packages, and then we have to configure ESLint to use pre-tears config or plugin. I don't remember. So it wasn't nightmare. I mean, sure, it takes 10 minutes, but why you have to do that? I mean, you shouldn't spend
so much time on these tools. And that's why BioM is there. Like you have one config with sensible defaults, which means that you just installed the dependency. And that's it. You don't need to do anything else. You just use it. If you don't like the defaults, okay, just you can run Bio in it and
change the defaults. And that's it. Also, you don't need to format the code that is fixed by your lint there because it's all in there. BioM does it for you. And it works out to the box in your editor. So what you get in the CLI, you get it as well in your editor. You don't need to do anything,
like anything at all. Instead, you can install the extension, of course. But other than that, you don't need to install three functions like pre-tier ESLint. You don't need to modify any configuration. So in there, it works out to the box most of the times, of course. So you see,
users spend the last time setting up their tooling so they can do programming as they want. Because that's what we like to do. We don't like to set up tooling. Absolutely. Diving into the tooling a bit, formatting has not changed significantly over the last few years, other than what the defaults may be or configuration the architecture is pretty stable. Linting on the other hand, BioM does
link things quite a bit differently than say, ESLint's back in before. What's the difference about a BioM interval versus say, a predecessor ESLint rule? Okay. So one thing that we recently shipped in BioM type of were rules and project rules. So we know that we have type script ESLint. Thank you, Josh, for what you shipped to us. So the existence of the ESLint that
leverage typescrate. So they provide useful rules, such as no floating promises or namis used promises. But they know that these kind of plugins need to do something that ESLint can't provide, such as scanning the whole project or the whole dependencies. Because these kind of rules need to understand not just the file that you have open on your editor, but they have to resolve types dependencies. So they need to do a lot of work in order to work. And that's something that
ESLint doesn't provide out of the box. But BioM does. So BioM in this case is able to scan your old project before starting the actual linting, is able to collect the batch of information so that we can provide powerful intros such as no import cycles. So it's able to fly over all the import tree of your project and understand if you're actually importing the same, you're doing a cycle, is able to scan your dependencies. So it understands if you're using a dependency that is not installed in your package. One thing that, for example, I recently merged is a lint rule that is able to
understand if you're using a CSS class that is not defined anywhere. So a bioM is able to scan the whole project, CSS files, JARSS files, view files, all the files, it collects all the information, and then it does the lint rule that inspects, I don't know, your component, your div or whatever, your element, it reads the classes that you use and it checks if they're actually defined somewhere in your project. And if they're not this as, oops, you're using a CSS class that it's not defined anywhere. And it's also able to show you the actual tree of components that they were analyzed. And that's something that is provided by the bio-mogograph, which is a language agnostic, in a sense, like is able to collect multiple languages or files or assets in the same time, like HTML, CSS, JavaScript, and so on. And I'm really proud of what they've done, because it's something that, like the tools
that we have today, they're not able to do that, or I mean, that I'm aware of, of course. So that's what bioM is able to provide that the current tools might lack, or they don't provide out to the bots. You've mentioned two big features. There's types of literals out of the box, and then there's the bio-mogograph. Talking about type of literals a little bit, how does that type information work in bioM? Yeah, so in bioM, we try to do things differently, because that's essentially our way
of doing things, like providing something different from what you have, so you can try it. So bioM does something called type inference. So it actually tries to collect and infer, as it says, the types of your code, like the JavaScript type three files. So the project and the efforts were led by another core contributor, and Vercel actually employed the contributor to actually ship the feature. So it was a great community effort, and it required a lot of resources and time. But now
we are able to ship literals that don't require the actual types of compiler. So you don't need TypeScript to understand if you're using incorrectly a promise. There's a dangling promise that you have innovated to. How does it work? Well, essentially, the engine relies heavily on the modograph in order to essentially collect and read all the files that the project uses, as well as the dependencies, so it's not just the project, but also all the libraries involved in the application. And then
there's a lot of work where it tries to flatten, for example, expressions, functions. I don't know all the details because the efforts were led by another core member. But I managed to actually fix a couple of bugs there, because the engine requires a lot of tools, such as not just the modograph, but also the semantic model. So just the other day, I fixed the bug where BioM couldn't infer the type of dependency. So there was import function from low dash, for example, and you couldn't understand if it was a promise or not. So and they fixed it the other day by integrating
the semantic model into the inference system. Or I was able to ship these other rules calls, and all the necessary conditions, which tells you, oh, you don't need to do this kind of check, because it's always true. Like you have a variable that is always true. So it tries to infer when, for example, it changes value and things like that. And at the end, when there's the if for whatever, it tells you, oh, there's no need to do any chat because this variable never changes. So it's true. So I'll wait and answer your question. Very much so. You mentioned another
type of graph now, semantic graph. What's the difference between a semantic graph and a model graph? So it's not called semantic graph, it's called semantic model. So the mod graph is just essentially a data structure that just checks. Okay, so this module, so this file is imported by this other file, and so on. So it's very generic. It tells you what imports, what exports, and there it is.
Not enough. Semantic model is actually more specialized. It's not a way of other files, it's just a way of one file. And it's very specialized to the kind of file. So in JavaScript, it specializes into the understanding, the values, scopes inside a file. So you have your
global scope, you have scopes and functions, then you have your arrow function that don't have scopes. So you have your classes, they have a different scope. So that's what this semantic model does. For example, it checks as well if a binding is exported or not. So it does very specialized things.
For CSS, for example, it focuses on calculating the specificity of your classes. So as you can see, it's very tied to the implied semantics of the language that you're handling. Surely we're going to have, for example, a semantic model for GraphQL. I don't know the language, other maintainers have more expertise than me, but they're not going to use it, they're going to create it so they can provide spatial ordering tools. The mod graph is just a big pile of data of all your files that you have. It's basically a trail and branches and leaves. And you have your edges,
how they are connected to each other. So it's mostly like a spiderweb and you have to navigate it to understand to collect the information that you need. What are the difficulties with building that rules specifically in native speed code? Is that many of the end users are its native speed developers? What are you in Biome doing to solve that developer interoperability difficulty? Well, I mean, as we mentioned, Biome has a plugin system to try to
bridge the gap. It's a plugin system based on this DSL called GridQL. So it was chosen some time ago as a winner after a lot of discussion. So we are aware that we can do everything. And there are some requirements that are project specific. So things like that belong to your org or to your employer,
to your code base. So that's where we think the plugin is actually very useful because also like your sensitivity data, things like that. So we have your this powerful DSL that Biome is able to interpret and it has its own runtime. And so with these plugins, users are able to inspect the code and just to let you know. So until now, these plugins were not able to provide code fixes.
So I think now it was just that's the role that's the diagnostic, there's the error, and that's it. So we have an IPR that is able to actually provide a code fix. So probably in the next minor user will be able to create an intro that is able to auto fix possible issues in their code base. So this actually gives my point where the plugins are bad. But I think in this case, are actually valid because the tool cannot know everything. And it shouldn't. Like I shouldn't
know about the quirks of your code base because they are sensitive data. And that's where the plugin makes sense. You leverage the tool, Biome, IsLink, OXE, whatever, and you apply it to your code base specifically to your needs because they belong to your project. So it sounds like you could use code fixes from liberals as a sort of code mod tool. Yes, yes, exactly. Look at that. That's really
cool though. So there's already a Biome search command and just looking through the Biome.js.dev slash reference slash great ql page, it looks like you can do some pretty powerful matches with not that much in text with great ql. Have you seen a lot of developers pick this up and use it? So I'm not into a lot of this part of the tooling. I know that there are users that have like a 70 or more Biome plugins written in Greek ql. So I feel like there are users that actually leveraging
the plugin system a lot. But yeah, like, Grid ql was born as a code model. That's why it's so powerful. That's why it has a lot of weird syntax because one of the initial objectives was to create code mods. And essentially, that's what Biome could potentially do in the future. You could create your code mod
to either not. You have your reactor from 18, 19, there's a lot of changes. You have your code mod, or even internally. So you're changing stuff. There's a lot of refactor. Create your plugin that does the
code mod run by on and there it is. Beautiful. Let's talk about the feature a little bit. What are some of the big flashy upcoming features in around Biome that you're excited about? Ah, that's nice. Okay. So there's a lot of going on. A lot of ideas. So one is this
link rule that I talked about that is able to catch unused classes. It's still early stages because there's a lot of components and ecosystem is big quirks. The second thing that we're working on is the watcher. So you can run Biome link dash dash watch and then you can start typing and Biome traffic change. It links the new file that you just changed and it checks if there are some violations or not. And I think it's also good work for the formatter, but I mean, it's still in your
listages. And the reason why we're able to do that is because Biome has already a watcher under the hood. So we're just exposing the watcher using this UI. One other thing that we're doing, this is just third party contributions. So I'm not doing that much. So plugins that will be able to emit code fixes
and they will be able also to set the severity. So until now, user, they couldn't do much. So now we are making plugins more powerful and customizable to our users. We're working towards markdown support. So internally, we reached 100% coverage against common market. This is also done by another
third party contributor. So that's amazing. I'm just essentially reviewing PRs and contributing with them. So it has an effort at the moment doing the refactor of the parser while keeping the conformance to common mark to 100%. And we're setting up the format at the moment. So if everything
goes well, it's going to be part of the next minor. Yeah, I think that's, I mean, there's also, like, we're doing a lot of link rules for review and also, that's probably going to start creating some link rules now that we have a very good handle on this bad syntax. So now we can start shipping some link rules for them. For Astro, I still need to investigate. I know there's a link plugin for Astro, but I'm not familiar with the rules. So probably there's a room for implementing something
there as well. It would be nice if the leader of the Astro project and the leader of the bio project is many of the same people together. Ah, yes. Which is it? What are the interesting notes you brought up was editor support. Can you tell our users what is LSP and what does that mean in this context?
Sure. So LSP stands for language server protocol. As the hardware says, it's a protocol to essentially create an editor server that works in all editor clients. Nowadays, the vast majority of the editor clients support this protocol. So like BS code, Z, web store, my only intelligent, sorry, JetBrains, IDs, VIM, Alex. So all of them now support LSP. And this is actually quite powerful
because we just need to develop the server in one place and then the access is the same in essentially all the editors. So one of the bias mission is to focus LSP as well. So to provide only one experience, which means that we implement the business logic in one place and then you get the same look and feel on the CLI, the LSP in the playground. So any client because bio and essentially a server, you have multiple clients. And that's what we do for rather than NOSDIC. So what you see in the CLI
is the same thing that you see in your editor. So something that we could potentially do in BioM that other tools can do is to leverage the model graph to implement things like the go to, you have a URL function, you want to know where it's defined us, you do common click and it takes you to the definition. So that's something that BioM could actually do. So there's an endless possibilities with BioM because everything is essential. We own the stack, we own the information, but still it requires essentially the timer. So I'm setting up essentially the whole infrastructure.
I have a lot of ideas. I just need the timer to implement them. Now with these AI agents, I get to do things quickly because like they just write the code and then review it. So I'll wait until I'm sorry question. That does. Before we start to wrap up, are there any other big
features or fixes for BioM that you're excited about coming years? No, like I really want to do a shout out to the actual community because a lot of fixes, a lot of new features have been developed by other people that are in the core team. So BioM is essentially a community effort. We are just essentially orchestrators and the manager, but we are seeing a lot of people sending fixes and in features. As I said, the markdown parser has been done by another person, the formatters as well.
We are actually also working on the CSS support, the SaaS support. So yeah, I want to do a shout out to all the contributors because a lot of things that you're using and other people are using have been shipped and created by the community session. Let's talk about the community then. BioM has been around for a few years now. It's outlast at Rome. It's clearly sustained itself. How have you been able to build a community where so
many open source projects are? Well, I think BioM has a concept, attracted a lot of people as I was. So that's just one of the reasons. Second, I don't know. I have some experience in open source.
I'm involved in other communities. So I learn from the other communities and apply it to the BioM's community. I try to be friendly every time. It's not easy. That's actually very difficult as a maintainer to keep your cool. And I know that sometimes I wasn't able to. And also, like,
you have to be active. We have our Discord chat. And if you're able to answer questions as quickly as possible, people eventually acknowledge that and they like it. Because sometimes you're in a project, you file an issue or you ask a question, and then it's basically you don't get the answer for weeks. So I think that's why I try to focus on quick feedback if I'm able to. And I think this is paying
off because users seeing that activity, they see that their problems are solved, the questions are answered, or maybe we don't have the answer. But at least there's some discussion. So there's something moves every single time. There's something to be said about positivity. You join the BioM Discord and all these fun channels. There are lots of emoji is exciting announcements. It feels like a
very big project and a fun place to be. Yeah, we try. We try to be active, to be positivity. And as you said, to communicate. That's also something that since day one I wanted to do. If there's
something about BioM anything related, just share it. Or even if it's not about BioM shared, you know, it's you have a link that you like, just drop it and people like it and go something nice to read. And so that's essentially the mentality. You are there. You want to share something and do it. You are more than welcome to do so. Let's say that I'm a listener with a large
code base, complex formatting, and so on. How would I get started trying to switch things over or to evaluate to BioM? So BioM has a couple of commands that allows you to read the config from ESLint and prettier and create a bioM coffee that matches as much as they can what you had before. Of course, we don't have all the ESLint rules, but at least something. Second, you can actually do first pass of your link by suppressing all the violations because you might have a lot of violations in the big code base. So you do BioM lint dash dash suppress, dash dash suppress
reason and say migration or whatever. And you're good to go. Maybe you can also turn off the formatting from all, but like we match 97% of prettiest formatting, so it should be good to go. But at least the linting is there. It doesn't scream at you and you can keep your code base there.
And then you can progressively address the intruders as you go. That's essentially what you could do for immigration. If you have a lot of formatting problems, my technique that I usually suggest is to add a PR, make sure the CI screen, merge it, and then goes with another PR that ignores the commit of formatting. So like your history is not mangled by the formatting. We do the same as in the bio- Great. Let's say that I have a new project. I want to get started fresh with BioM. How is that
so you start BioM and you're good to go. You could run BioM in it, which puts up a BioM config for you, which essentially mirrors our defaults. So it might be lengthy, but at least you can see what are our defaults. You don't need to go to the website. You can understand what's the default and then you can change it like tabs versus spaces, lint rules and so on. Other than that,
we actually put a really nice tool called the BioM explainer from the CLI, where you can just type BioM explainer, no debugger, and it shows you the docs right in the CLI. So if you don't have any connection and you know the name of the internet connection and you don't want to go to the website, you just type that command and you can see what the link rule does for you. Speaking of which, that website is BioJs.dev. Yes. Great. Are there any other resources or links you want to send
people to if they want to learn about BioM? I think the website is quite several explanatory, also the main hit up repo. It's also a nice resource. And yeah, we try to be central. So we try to have everything in one place and the website is where everything goes and our discord. So
BioM.js.dev slash chat and you should be good to go. Excellent. I like to add the reviews with one non-word question. You mentioned at the very beginning that you were interested in video games, what games are you playing these days? So the one I'm playing, us as in Scrit Shadows, I'm not a big fan of the whole saga, but I like the last video games there because I'm really focused on role playing. So you have your character, you choose your skill that you
want to develop, your weapons, skills and things like that. So in Japan, which I really like, so it's a really nice mix of things. I really like role playing. So GDR and things like that, RPG. Essentially, I'm not into like sports or shooting every like RPGs. Fun. Are there any lessons
you've learned in programming that apply to the stories of these video games or vice versa? If you want to learn how to do video game, you have to do it yourself. Just do yourself like a lot of people do in the video games. That's how I think you should start. I mean, I tried the university. It didn't pan out. So do yourself if you have the passion and the time, I don't have
the time anymore. So that's the only problem. But if you have the time and the passion to yourself, I mean, the tools that we have nowadays, I think it's quite easy to pick up. All you need is time, interest and energy. Yes. Okay. Emma, this has been wonderful. Thank you for
walking us through your history and bio and other fun things around analyzing and lifting that count with it. If people wanted to learn more about you specifically, where do you directly be going into that? They can go to my blue sky account, amatypical.xyz and the GitHub account. Yeah, I mean, that's essentially where you can find me and where I'm active. I'm not a real social person. I like to work and I engage less. Excellent. Well, thank you for all the info for
software engineering data. This has been Emma and Josh Wilberg. Cheers, everyone. Thanks.