KBall interviews Nick Nisi about the Pandora’s box that is his tooling/developer setup. Starting at the lowest layer of the terminal emulator he uses, they move upwards into command line tools, into Tmux (terminals within terminals!), his epic NeoVim configuration, and finally into the tools he uses for notekeeping and productivity.

Nick is excited to explain CVA to us like we’re five (then again like we’re 41).
KBall is excited to share details of his new stack (for the new app he’s building).
Jerod is excited to share some recent news items (but he’s the only one).

And finally, we’re all excited to debate TypeScript vs JSDoc comments!

Nick & KBall sit down with the brilliant Stephen Haberman to discuss all things ORMs! 💻🔍

From the advantages and disadvantages of ORMs in general, to delving into the intricacies of his innovative project Joist, which brings a fresh, idiomatic, ActiveRecord-esque approach to TypeScript. 🚀

So sit back, relax, and let’s dive deep into the world of ORMs with the experts!

There are a ton of problems around building LLM apps in production and the last mile of that problem. Travis Fischer, builder of open AI projects like @ChatGPTBot, joins us to talk through these problems (and how to overcome them). He helps us understand the hierarchy of complexity from simple prompting to augmentation, agents, and fine-tuning. Along the way we discuss the frontend developer community that is rapidly adopting AI technology via Typescript (not Python).

TypeScript PM, Daniel Rosenwasser:

This release brings many new features, while aiming to make TypeScript smaller, simpler, and faster. We’ve implemented the new decorators standard, added functionality to better support ESM projects in Node and bundlers, provided new ways for library authors to control generic inference, expanded our JSDoc functionality, simplified configuration, and made many other improvements.

Homebrew creator Max Howell is back with a brand new invention:

tea is a standalone, binary download for all platforms that puts the entire open source ecosystem at your fingertips. Casually and effortlessly use the latest and greatest or the oldest and most mature from any layer of any stack. Break down the silos between programming communities, throw together scripts that use entirely separate tools and languages and share them with the world with a simple one-liner.

All you need is tea.

Bold! I love how many interesting ideas are packed in to this project: pipelines, universal virtual-env, executable markdown… the list goes on. Check out the README for all the deets. My big question is: might Max and the team be thinking too big this time around?

I, for one, welcome our new Rust overlords.

Full-stack web development is (still) too complicated. Simple CRUD, a common requirement of any business application, should be simple to build, maintain, and extend when the need arises.

Remult is a full-stack CRUD framework that uses your TypeScript entities as a single source of truth for your API, frontend type-safe API client and backend ORM.

This isn’t just production-ready, it’s been used in production since 2018.

Hang with Jerod, Nick & KBall while we discuss what’s new & noteworthy in the web world. Cloudflare Turnstile, Linkify 4.0, TC39 updates, the Figma acquisition, Penpot, pay transparency, and more! We might even discuss TypeScript if Nick gets his way…

Nick Nisi hasn’t played it yet, but he’s already declared TDungon to be the “Game of the Year”…

This looks very opinionated with the tech it chooses (Node, Express, MongoDB, React, TypeScript). But if you like those choices, that probably means you’ll like what they’ve cooked up.

• Payload gives you everything you need, but then steps back and lets you build what you want in JavaScript or TypeScript - with no unnecessary complexity brought by GUIs. You’ll understand how your CMS works because you will have written it exactly how you want it.
• Bring your own Express server and do whatever you need on top of Payload. Payload doesn’t impose anything on you or your app.
• Completely control the Admin panel by using your own React components. Swap out fields or even entire views with ease.
• Use your data however and wherever you need thanks to auto-generated, yet fully extensible REST, GraphQL, and Local Node APIs.

This isn’t the first attempt at making regular expressions more approachable, but it’s the first one I’ve seen that also brings type safety to the table. Example code:

import { createRegExp, exactly, oneOrMore, digit } from 'magic-regexp'

// Quick-and-dirty semver
createRegExp(
  oneOrMore(digit)
    .as('major')
    .and('.')
    .and(oneOrMore(digit).as('minor'))
    .and(exactly('.').and(oneOrMore(char).as('patch')).optionally())
)
// /(?<major>(\d)+)\.(?<minor>(\d)+)(\.(?<patch>(.)+))?/

Jerod, Nick & Ali partake in a few rounds of Story of the Week, TIL, and I’m Excited about $X. Oh, and is TypeScript the new Java? Nick responds and emotes all over the place! 😆

Josh Goldberg joins Nick, Chris & a very nasally-sounding KBall for a fun conversation around TypeScript ESLint. They discuss why we need ESLint when we have TypeScript, some useful rules in typescript-eslint, how it works, and a few hot takes along the way!

In 2020, Shawn (swyx) Wang wrote:

Every 10 years there is a changing of the guard in JavaScript. I think we have just started a period of accelerated change that could in thge future be regarded as the Third Age of JavaScript.

We’re now in year three of this third age and Swyx joins us to look back at what he missed, look around at what’s happening today, and look forward at what might be coming next.

Since TypeScript doesn’t follow SemVer itself, TS libraries which do want to follow SemVer need both high-level guidance about how to do that and detailed analysis of the corner cases to watch out for as well as ways to mitigate breaking changes from TS.

This doc is a (beta!) specification of SemVer for managing changes to TypeScript types, including when the TS compiler makes breaking changes in its type-checking and type emit across a “minor” release.

Daniel Rosenwasser and Ryan Cavanaugh from the TypeScript team at Microsoft join Nick and Boneskull to catch us up on the latest happening with the TypeScript project, including what’s exciting in the new 4.7 beta release. Then, we dive deep into the new, TC-39 stage 1 Type Annotations proposal, what it is, and what it means for the future of a not really typed JavaScript!

This proposal is brand new (stage 0), but I hear that a lot of work has been put into it behind the scenes by a lot of people, so it has that going for it…

This proposal aims to enable developers to add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript. At runtime, a JavaScript engine ignores them, treating the types as comments.

The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation, if they stick within a certain reasonably large subset of the language.

The implications of this change are pretty massive, if it were to ever ship. And you better believe we’re putting together a JS Party episode to discuss it with the people involved.

Many of us use TypeScript in our React applications to eliminate an entire class of runtime bugs. But surprisingly, one of the most commonly used types: React.ReactNode turns out to be unsafe, failing to detect objects that cannot be rendered by React. This post digs into what is going on and how to fix it in your system.

Tim Raderschad shares some knowledge he acquired the hard way. The tricks are:

1. Readonly
2. Any vs Unknown
3. Typing Objects with Records

I knew exactly zero of these (although I’ve only written a few hundred lines of TypeScript thus far. I’m mostly ignoring it so I can retain my arch nemesis status with Nick (the perpetual TypeScript bull) on JS Party. 😉)

Doug Martin joins Nick to talk to us about building GraphQL backends in TypeScript with NestJS and his project, nestjs-query. We talk about what NestJS is and its built-in support for GraphQL and REST, and then dive into how NestJS-query extends it to generate code for you.

Turns out Niek and his team were also inspired by other Todo or Die implementations:

Lately, there is some talk about Todo or Die plugins in languages. According to your latest newsletter, it is now supported in Rust, Ruby, Python, and Elixir. We’ve now added support for TypeScript as a language server plugin!

For now, it has a minimal feature set, because this was created in a day during our company’s Innovation Day, but we have lots of ideas to extend the project.

Tanner joins Nick to talk about his projects, react-query and react table, and discuss scratching your own itch in a maintainable way with open source.

Ever wanted a language like JavaScript, but without the warts, with a great type system, and with a lean build toolchain that doesn’t waste your time?

Patrick Ecker from the ReScript Association sits down with Jerod and Feross to tell us all about this “JavaScript-like language you have been waiting for”.