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.

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>(.)+))?/

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.

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. 😉)

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.

Use TypeScript as your preprocessor. Write type‑safe, locally scoped classes, variables and themes, then generate static CSS files at build time.

First-class theming, framework agnostic, and type-safety so you can cow[boy|girl] code those styles and let your tooling catch typos and variable name changes.

tRPC doesn’t generate code for you, add functions to your run-time, or require any additions to your build pipeline. It simply allows your client code to be aware of your server-side type annotations and declarations so you can have type-safety and autocompletion inferred from its API paths, input/output data, and errors.

A (potentially) landmark feature landed in Deno 1.6:

deno compile --unstable https://deno.land/std@0.79.0/examples/cat.ts will make you an executable version of the module.

This puts Deno-based TypeScript projects in the same league as Go and Rust by providing a way to distribute software without the pain of dynamically linking multiple files. (This single-binary distribution has made Go a popular choice for projects such as the GitHub CLI and Stripe CLI.)

Node has had a similar capability by way of Vercel’s pkg project, but Deno sets itself apart by supporting the feature as part of the runtime itself.

From Microsoft’s TypeScript wiki on GitHub:

There are easy ways to configure TypeScript to ensure faster compilations and editing experiences. The earlier on these practices are adopted, the better. Beyond best-practices, there are some common techniques for investigating slow compilations/editing experiences, some common fixes, and some common ways of helping the TypeScript team investigate the issues as a last resort.

Martijn de Haan:

It’s been almost 3 years since I started working on this query builder idea of mine. Today is finally the day Mammoth hits 1.0. Mammoth is a no-batteries-included type-safe Postgres query builder for TypeScript. Hooray!

Congrats on shipping, Martijn! Here’s a peak at the API:

const rows = await db
    .select(db.foo.id, db.bar.name)
    .from(db.foo)
    .leftJoin(db.bar)
    .on(db.bar.fooId.eq(db.foo.id));

ts-migrate is a tool for helping migrate code to TypeScript. It takes a JavaScript, or a partial TypeScript, project in and gives a compiling TypeScript project out.

ts-migrate is intended to accelerate the TypeScript migration process. The resulting code will pass the build, but a followup is required to improve type safety. There will be lots of // @ts-expect-error, and any that will need to be fixed over time. In general, it is a lot nicer than starting from scratch.

ts-migrate is designed as a set of plugins so that it can be pretty customizable for different use-cases. Potentially, more plugins can be added for addressing things like improvements of type quality or libraries-related things (like prop-types in React).

Marius Andra added TypeScript support to his React state management library with kea-typegen:

I tried a lot of different ways to add TS support to Kea. At the end of the day what was needed was just not possible without an extra type generation step. I’ll document the failed attempts in a blog post one day. The issue boils down to the fact that each block inside a logic (e.g. reducers) gets the logic itself as a parameter (reducers: logic => (...)). That kind of loopy stuff is just not possible with TS right now. At least not to the level that it has to be for it to work in Kea (think of selectors that depend on each other). Ultimately, all of the pure-TS attempts I tried would have yielded a partial solution.

Thus kea-typegen was born. Even if it’s just a step along the way (TS compiler plugins a’la babel someday?) and still missing many features, it’s already really useful. It uses the TypeScript compiler API to analyse your source files and print out complete types (interfaces) for them.

Marius also recorded a video of the process in action.

Orta Therox, making the big announcement on behalf of the Svelte team:

We think it’ll give you a much nicer development experience — one that also scales beautifully to larger Svelte code bases — regardless of whether you use TypeScript or JavaScript.

Up until now TypeScript was usable with Svelte, but not officially supported by the project. What does that official support look like?

• You can use TypeScript inside your <script> blocks — just add the lang="ts" attribute
• Components with TypeScript can be type-checked with the svelte-check command
• You get autocompletion hints and type-checking as you’re writing components, even in expressions inside markup
• TypeScript files understand the Svelte component API — no more red squiggles when you import a .svelte file into a .ts module

I know a lot of people have been waiting for this. Congrats to all involved on a big release!

Results are in for the 2019 State of JS survey. I’ve been digging through charts to see what I can see. Here are 7 insights that jumped off the page to me.

Mat Ryer created this fun Go Time promo at JavaScript’s expense. Should Johnny use Go or TypeScript? 😉

Nintendo has been slowly bringing their iconic games and characters to mobile platforms. Maybe it’s time they consider the web platform? 😉

Gotta love when a library is so small that Logbot can JIT inline it in the News and save us precious clicks…

import React from "react"

export interface ContainerProviderProps {
	children: React.ReactNode
}

export interface Container<Value> {
	Provider: React.ComponentType<ContainerProviderProps>
	useContainer: () => Value
}

export function createContainer<Value>(useHook: () => Value): Container<Value> {
	let Context = React.createContext<Value | null>(null)

	function Provider(props: ContainerProviderProps) {
		let value = useHook()
		return <Context.Provider value={value}>{props.children}</Context.Provider>
	}

	function useContainer(): Value {
		let value = React.useContext(Context)
		if (value === null) {
			throw new Error("Component must be wrapped with <Container.Provider>")
		}
		return value
	}

	return { Provider, useContainer }
}

export function useContainer<Value>(container: Container<Value>): Value {
	return container.useContainer()
}