The TypeScript programming language.
View All Tags
The MUI X Data Grid is a really handy component for rendering tabular data in React applications. But one thing that is not immediately obvious is how to use TypeScript to ensure that the columns you pass to the component are correct. This post will show you how to do that.
Why does it matter? Well look at this screenshot of the Data Grid with incorrect column names:
It's possible to statically type check a JavaScript codebase with TypeScript with JSDoc annotations. Going a little further, and using typescript-eslint to lint your codebase with the benefits of type information can improve your code quality even more. This post will show you how to set this up and talk about some of the gotchas.
We'll also talk a little about how to use TypeScript in combination with JSDoc annotations in a JavaScript codebase.
I've written previously about combining Web Workers and Comlink. I recently found myself needing to use Web Workers again. As I picked them up this time I found myself making some different choices, now I was working in a codebase that used Vite to build. I ended up using TanStack Query in combination with my Web Workers and Comlink. It was a really good fit and this post will show you how to use Web Workers with Comlink and TanStack Query.
If you need to publish a package that supports both ECMAScript modules (ESM) and CommonJS modules (CJS), you can use tsup to do so. This post will show you how to do that and how to ensure that the types are correct using the tool Are the Types Wrong?.
I'm a longtime user of TypeScripts noUnusedLocals and noUnusedParameters settings. I like to avoid leaving unused variables in my code; these compiler options help me do that.
I use ESLint alongside TypeScript. The no-unused-vars rule provides similar functionality to TypeScripts noUnusedLocals and noUnusedParameters settings, but has more power and more flexibility. For instance, no-unused-vars can catch unused error variables; TypeScript's noUnusedLocals and noUnusedParameters cannot.
One thing that I missed when switching to the ESLint option is that, with noUnusedLocals and noUnusedParameters, you can simply ignore unused variables by prefixing a variable with the _ character. That's right, sometimes I want to declare a variable that I know I'm not going to use, and I want to do that without getting shouted at by the linter.
It turns out you can get ESLint to respect the TypeScript default of ignoring variables prefixed with _; it's just not the default configuration for no-unused-vars. But with a little configuration we can have it. This post is a quick guide to how to implement that configuration.
There's a new programming model available for Node.js Azure Functions known as v4. There's documentation out there for how to migrate JavaScript Azure Functions from v3 to v4, but at the time of writing, TypeScript wasn't covered.
This post fills in the gaps for a TypeScript Azure Function. It's probably worth mentioning that my blog is an Azure Static Web App with a TypeScript Node.js Azure Functions back end. So, this post is based on my experience migrating my blog to v4.
This post grew out of my desire to improve the metadata for my blog posts. I have been blogging for more than ten years, and the majority of my posts lack descriptions. A description is meta tag that sits in a page and describes the contents of the page. This is what this posts description meta tag looks like in HTML:
<meta
name="description"
content="Use the TypeScript Azure Open AI SDK to generate article metadata."
/>
Descriptions are important for search engine optimisation (SEO) and for accessibility. You can read up more on the topic here. I wanted to have descriptions for all my blog posts. But writing around 230 descriptions for my existing posts was not something I wanted to do manually. I wanted to automate it.
I am excited to announce that a documentary has been made about TypeScript! It premiered on YouTube at 5pm British Summertime September 21st 2023.
I had the good fortune to be involved in the making of the documentary. In part this was thanks to my work on Definitely Typed. Another reason was my work on recording the history of DefinitelyTyped.
You can see it on YouTube here or hit play on the embedded video above. Thanks to the Keyboard Stories team for making this happen!
A new feature arrives with TypeScript 5.1, it is described as "Decoupled Type-Checking Between JSX Elements and JSX Tag Types".
It's all about handing control of JSX type definitions to libraries. With this feature, libraries can control what types are used for JSX elements. Why does this matter? Great question! Until version 5.1, TypeScript did an imperfect job of representing what is possible with JSX. This feature allows libraries to do a better job of that, and we'll look into it in this post.
It's probably worth saying, that this is a complicated feature. If you don't understand it (and as the author of this post I'll confess that I had to work quite hard to understand it), that is okay. This is a low level feature that is only likely to be used by library / type definition authors. It's a primitive that will unlock possibilites for people writing JSX - but it's something that people will mainly feel the benefit of, without directly doing anything themselves, or necessarily noticing that things have changed for the better.
I really like type imports that are unambiguous. For this reason, I've made use of the "importsNotUsedAsValues": "error" option in tsconfig.json for a while now. This option has been deprecated in TypeScript 5.0.0, and will be removed in TypeScript 5.5.0. This post will look at what you can do instead.
I wrote previously about how to implement a dynamic redirect mechanism for Azure Static Web Apps using Azure Functions. I implemented this using JSDoc JavaScript. I've since migrated this to TypeScript and I thought it would be interesting to share the process.
I've wanted to take a look at some of the alternative JavaScript runtimes for a while. The thing that has held me back is npm compatibility. I want to be able to run my code in a runtime that isn't Node.js and still be able to use npm packages. I've been using ts-node for a long time now; it's what I reach for when I'm building any kind of console app. In this post I want to port a console app from ts-node to Bun and see how easy it is.
Support for Node.js 16 for Azure Pipelines custom pipelines task extensions has arrived. From a TypeScript perspective, this post documents how to migrate from a Node.js 10 custom task to one that runs on Node 16 using azure-pipelines-task-lib.
It's now possible to use Node.js 20 in tasks! See more details below:
What's more we're going to start to see warnings emitted in pipelines when an EOL Node version is used.
The React useState hook is a great way to persist state inside the context of a component in React. This post demonstrates a simple React hook that stores state in the URL querystring, building on top of React Routers useSearchParams hook.
Logs matter. In Azure, logs generally live in Application Insights, in the Transaction Search section. This post reverse engineers the Azure Application Insights Transactions URL, and details how to construct a link to take you directly there, using both TypeScript and C#.
As part of the TypeScript 4.7 release comes a major upgrade to ECMAScript Module Support for Node.js. This post takes a look at what that means.
The upgrade of the React type definitions to support React 18 involved some significant breaking changes. This post digs into that and examines what the upgrade path looks like.
Recently, a new ECMAScript proposal called "Type Annotations" (originally named "Types as Comments") was revealed. The purpose is to allow type annotations to be valid JavaScript syntax. Albeit syntax that is ignored by JavaScript engines. The proposal is being worked on by Gil Tayar, Daniel Rosenwasser, Romulo Cintra, Rob Palmer, and others. Many of these people are from TypeScript community - however this proposal intentionally does not exist to benefit TypeScript alone.
There's a debate to be had about whether using JavaScript or TypeScript leads to better outcomes when building a project. The introduction of using JSDoc annotations to type a JavaScript codebase introduces a new dynamic to this discussion. This post will investigate what that looks like, and come to an (opinionated) conclusion.
If you'd like to learn more about setting up a codebase to be type checked with JSDoc and TypeScript, then read this guide.