Start Building Your Own JavaScript Tools

Rate this content
Bookmark

Your first JavaScript tool might not be the next Babel or ESLint, but it can be built on them! Let's demystify the secret art of JavaScript tools, how they work, and how to build our own. We'll discover the opportunities in our everyday work to apply these techniques, writing our own ESLint rules to prevent mistakes and code transforms to make breaking changes easy to apply. We’ll walk through the fundamentals of working with an abstract syntax tree, and develop our understanding through a live-code. You will be amazed at what you can build, and together we’ll explore how to get started.

Will Klein
Will Klein
22 min
05 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

[♪ music ♪ by The Illuminati plays)] I see a common thread across any project I work on. Different developers are making the same mistake and we have preferred ways of doing things. Preventing mistakes and sharing best practices are great reasons to look at tools like linters and in particular ESLint. Let's write our first rule together. We're just scratching the surface of building our own tools, which can have a massive impact on improving the developer experience.

1. Introduction to Building Custom Tools with ESLint

Short description:

[♪ music ♪ by The Illuminati plays)] I see a common thread across any project I work on. Different developers are making the same mistake and we have preferred ways of doing things. Preventing mistakes and sharing best practices are great reasons to look at tools like linters and in particular ESLint. Let's write our first rule together. I'm going to share a little about what I work on and a problem I like to solve where I think would be really helpful. Right now, I work on a design system called Canvas and we provide a component library for UI developers to use. We invest a lot into making our components accessible and useful across a wide range of use cases. Let's dive in.

[♪ music ♪ by The Illuminati plays)] [♪ music ♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ by The Illuminati plays♪ show you how. What if we could get started with building our own tools? Where would we begin? What if the tools were specific to our project? Uniquely helpful and tailored to our needs? What if we could learn how to do this in the next 20 minutes learning what we need to know and how to take our first steps? In the next 20 minutes, let's write our first printing rule, write our first code mod, look at our first AST and build our understanding of them, and learn the fundamentals of how our tools work. Let's dive in.

I see a common thread across any project I work on. Different developers are making the same mistake and we have preferred ways of doing things while it's hard to communicate that to everyone else on our project or using our library. Preventing mistakes and sharing best practices are great reasons to look at tools like linters and in particular ESLint. Not only can we use ESLint's existing rules to handle many problems, but it has a rich ecosystem of plugins specific to different areas and we can write our own rules and plugins, which I'll show you how. ESLint rules are great for problems or mistakes that keep coming up, creating a better feedback loop for developers as they're writing their code, automating code review feedback, sharing best practices, and preventing anti-patterns in our code bases. Rules can be for any project, maybe just for your app, helping developers on your immediate team or others in a shared code base. If you maintain a library, they can help anyone using your library. Anyone can write these rules, not just project maintainers or expert developers.

All right, let's write our first rule together. I'm going to share a little about what I work on and a problem I like to solve where I think would be really helpful. Right now, I work on a design system called Canvas and we provide a component library for UI developers to use. We invest a lot into making our components accessible and useful across a wide range of use cases. As part of that effort, we maintain three different packages for our components, main, preview, and labs. We usually build new components in labs or preview, and as we prove out the API, refine design and make sure accessibility is perfected, we'll promote things from labs and preview up to main. This presents a somewhat unique challenge though. We have some old components, usually in main, that are going to be replaced by newer ones in labs or preview. When a developer is choosing between the two versions though, which way do they go? Sometimes, we really want to tell developers to use the newer one in labs or preview. We already plan to promote it to main in an upcoming release. The component is ready to use and has some benefits we don't want our users to miss out on. How do we communicate this? We do what we can with our docs and sending out announcements, but the best way is to tell them as they write their code. I'm pulling up an online tool that I use to test out new rules. Usually I'll develop with a test suite writing, Lint rules is a really good use case for test driven development. This tool is great to explore the problem, get a first draft, and often that's enough. This is astexplorer.net. There are a few things going on here, but I'll explain how each part works. On the left, there are two editors placed for the code we're working on on the top left and editor for writing an AS Lint rule down below and other tools as well. On the right, we have an AST viewer up above and the output window for debugging below that.

2. Understanding AST and Sample Code

Short description:

In the header, we can configure the parser and transform type. The AST viewer is amazing and we're going to explore it. An AST is just a tree that stores the syntax of our code. We can tell ESLint what we care about by specifying node types. Looking at this gives us everything we need to detect patterns. Let's look at some sample code that includes imports for our components. We have a not preferred situation with a segmented control component. When we selected the transform for ESLint V8, we got some sample code with a create function that returns an object literal.

In the header, we can also configure the parser and transform type which I've already set to Babel AS Lint parser and AS Lint v8. Besides giving us a really useful development environment, this AST viewer in the top right is amazing and we're going to explore it in a bit.

AST is an acronym for abstract syntaxtry. If you didn't study computer science at university though, the terminology for an AST might seem intimidating. I promise you though, it's just a tree and if you've worked with a DOM for a webpage, you know how a tree works. An AST just has the syntax for our code stored in it. We can explore this tree in the AST Explorer. It's also worth mentioning that the tree is basically a JavaScript object. There's nothing really new here. Like an HTML tag at the top of a webpage, that being the top node of the tree in the DOM, the top of the AST is the program node. This program node has child nodes such as the ones under body. Here we've got multiple import declarations and these import declarations have children of their own and so on. There's another type of property on a node that's very important, the type. This is how we're going to tell ESLint what we care about. We're going to tell it this for this node type. We want to hear about it and ESLint is going to handle walking the tree and any time it node that we care about it's going to pass it into a function that we can control and define. There are also some properties to describe each node, like the source type being module on the program. There are other values that we can look at that can be really helpful depending on the node we're working with. Looking at this gives us everything we need to detect patterns which is what an ESLint rule is doing.

Let's look at some sample code that includes imports for our components. On the top left we've got a couple different examples, a few actually. First there's the not preferred situation where we have a segmented control component that is coming from our main package CanvasKit React here. That is not preferred because we have a newer one in CanvasKit Preview React. This is our preview package. We want to direct developers to using that over our main package at some point. When we selected the transform for ESLint V8, we got some sample code in the bottom left. This is awesome because it's going to give us a place to kick off. I've cleaned it up a little bit down to its bare essentials. What we have is a create function. This create function returns an object literal.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vite: Rethinking Frontend Tooling
JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Top Content
Vite is a new build tool that intends to provide a leaner, faster, and more friction-less workflow for building modern web apps. This talk will dive into the project's background, rationale, technical details and design decisions: what problem does it solve, what makes it fast, and how does it fit into the JS tooling landscape.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
How Bun Makes Building React Apps Simpler & Faster
React Day Berlin 2022React Day Berlin 2022
9 min
How Bun Makes Building React Apps Simpler & Faster
Bun’s builtin JSX transpiler, hot reloads on the server, JSX prop punning, macro api, automatic package installs, console.log JSX support, 4x faster serverside rendering and more make Bun the best runtime for building React apps

Workshops on related topic

Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Hussien Khayoon
Kahvi Patel
2 authors
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
WorkshopFree
Ryan Albrecht
Ryan Albrecht
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real.
Join Sentry developer Ryan Albrecht in this talk to learn how developers can use Session Replay - a tool that provides video-like reproductions of user interactions - to identify, reproduce, and resolve errors and performance issues faster (without rolling your head on your keyboard).
Build React-like apps for internal tooling 10x faster with Retool
JSNation Live 2021JSNation Live 2021
86 min
Build React-like apps for internal tooling 10x faster with Retool
Workshop
Chris Smith
Chris Smith
Most businesses have to build custom software and bespoke interfaces to their data in order to power internal processes like user trial extensions, refunds, inventory management, user administration, etc. These applications have unique requirements and often, solving the problem quickly is more important than appearance. Retool makes it easy for js developers to rapidly build React-like apps for internal tools using prebuilt API and database interfaces as well as reusable UI components. In this workshop, we’ll walk through how some of the fastest growing businesses are doing internal tooling and build out some simple apps to explain how Retool works off of your existing JavaScript and ReactJS knowledge to enable rapid tool building.
Prerequisites:A free Retool.com trial accountSome minimal JavaScript and SQL/NoSQL database experience
Retool useful link: https://docs.retool.com/docs