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.

Nick, and Kball are joined by Mike Hartington to talk about Ionic, the state of web components, developer tooling, and more!

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));

Ben Ilegbodu joins Divya, Suz, & Amal to talk about introducing TypeScript at Stitch Fix, why TypeScript and React work well together, building component libraries, and more.

We kick off with some exciting TypeScript news, follow that with some exciting JavaScript news, then finish off with an exciting interview. Key word: EXCITING

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!

Nick and Jerod welcome Dojo’s Matt Gadd to the show to catch us up on what’s changed with the framework since episode #25, what’s coming in version 7, and to defend Nick’s comment that if you like React you just might like Dojo better.

Divya and Nick welcome Deno’s Kit Kelly to the show to celebrate the highly-anticipated new JavaScript/TypeScript runtime’s big 1.0 release.

This is a wide-ranging discussion about all things Deno. We discuss why they’re using Rust, how they’re rewriting parts of the TypeScript compiler, their take on package management, what adoption looks like, their code of conduct, and more.

Jerod, Divya, Chris, KBall, & Nick ring in the new year with our 2020 predictions, wish lists, & resolutions. Will Chrome’s browser market share decrease? Will Svelte (or a Svelte-alike) continue to trend? Will Jerod finally write some TypeScript?! Listen along and let us know your thoughts on the matters.

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? 😉

KBall, Divya, and Chris talk about what’s going on in all the big frontend frameworks, share some pro tips, and shout out awesome people and things in the community.

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()
}

Despite all the recent hype, setting up a new TypeScript (x React) library can be tough. Between Rollup, Jest, tsconfig, Yarn resolutions, TSLint, and getting VSCode to play nicely….there is just a whole lot of stuff to do (and things to screw up). TSDX is a zero-config CLI that helps you develop, test, and publish modern TypeScript packages with ease–so you can focus on your awesome new library and not waste another afternoon on the configuration.

Almost 6 months ago I have made a decision to move all our frontend projects from Flow to TypeScript. It was a tough battle inside my head. So, I have decided to write it down to help other people to choose the right tool. And not to make my mistakes.

We made a silly joke on Twitter yesterday (this is what Twitter is for, no?) about test doubles and that unfortunate moment when they inevitably surprise you.

This prompted Shlomo Kraus to reach out and tell us about Mockshot. In brief:

Imagine you could:

1. Never manually write a mock again
2. Have a guarantee that your mocks are always valid

Sounds nice! It works by using Jest’s snapshot tests output to generate mocks to be used in other tests.

This is purposeful coupling, which seems like it could backfire in the long-run. However, the team behind the library has been using it for over a year and are still singing its praises. For more on their experience creating and using it, read this.

You can npm install type-fest and use them in your project or simply bookmark this as a reference for the many advanced types that are built in to the TypeScript project itself. Submitting your own types is promoted. Also, a good idea on declined types:

If we decline a type addition, we will make sure to document the better solution here.

Lambcycle is a middleware for lambda functions. It defines a configurable life-cycle and allows you to focus on your application’s logic. It has a “Feature as Plugin” approach, so you can easily create your own plugins or reuse your favorite packages with very little effort 🐑 🛵.

The author goes deep on why Lambcycle solves a serious problem over on Medium.

Panelists Nick Nisi, Suz Hinton, and Kevin Ball chat about the perceived Great Divide in front end development, why 2019 is the year of TypeScript, and shout outs to inspirational members of the community.

Kent C. Dodds shares the backstory of paypal-scripts, a tool that encapsulates all the tools common to PayPal applications and published modules and why TypeScript was a fit. Kent took a poll in their #paypal-scripts Slack channel and 100% of respondents said they wanted the change. Here’s what happened next…

About a week later, I had totally migrated paypal-scripts from supporting Flow to supporting TypeScript (most of that time was making all the tools recognize .ts and .tsx files 🙄 and allowing paypal-scripts to dogfood itself which is kinda tricky 🐶).
…
Then we had Christmas break 🎄 and the week we got back after the new year 🎆, it was merged and now every new project starts off with modern tools that will stay updated by default and will be statically typed with TypeScript.

Nick, KBall, and Chris respond to follow up on the State of JavaScript survey, discuss Chromium, Edge, and the future of the web, and reminisce about the past year in the final JS Party of 2018!

DevHub helps you take back control of your GitHub workflow and stay on top of everything important going on.

Available on the web, iOS, and Android (thanks to React Native).