Need to manually type a JSON file?

I learned today that you can add a `.d.json.ts` file to manually assign a type to a JSON import.

For example, if you have a `data.json` file, you can create a `data.d.json.ts` file and define the type inside:

```ts
// data.d.json.ts
declare const data: Record<string, string>;

export default data;
```

You can change the `Record<string, string>` type to match the desired shape.

To make TypeScript recognize `.d.json.ts` files, you need to add a setting in your `tsconfig.json`:

```json
{
  "compilerOptions": {
    "allowArbitraryExtensions": true
  }
}
```

This setting lets TypeScript use `.d.json.ts` files.

## Why Would You Do This?

This technique can be particularly useful when working with large `.json` files used for test fixtures. If TypeScript infers the type of all the data in the file, it can significantly slow down the TypeScript transpilation process - and your IDE.

By assigning a broader type like `Record<string, string>`, TypeScript will use the specified type instead. This optimization can greatly improve the performance of your TypeScript transpilation.


Learn how to manually assign types to JSON imports in TypeScript by creating `.d.json.ts` files, which can greatly improve performance.

Override the Type of a JSON File

Node 23 will soon be able to run TypeScript files without any extra configuration.

[Marco Ippolito](https://x.com/satanacchio), who has been driving TypeScript support in Node for the last year, landed a [PR](https://github.com/nodejs/node/pull/56350) unflagging `--experimental-strip-types` in Node 23.

Practically, this means a few things:

- You can create an `index.ts` file containing TS syntax, like type annotations.
- You can run `node index.ts` with no further flags
- Node will strip out the types using a version of `swc`, then run the resulting code.

Let's treat this article as a FAQ:

## How Can I Try It?

It's now available in the Node Nightly version, as mentioned by [Marco](https://x.com/satanacchio/status/1872574795390530000). In a few days it'll likely get a release in Node 23.

UPDATE: Looks like it's coming to [23.6.0](https://github.com/nodejs/node/pull/56450).

## Will Node Typecheck My Files?

No. Node will not typecheck your files when it runs them. This is a good thing - it means that typechecking can run in a separate process to running your app.

You'll need to run `tsc --watch` locally to typecheck your app as you work.

## What Should Be In My `tsconfig.json`?

This is a tailored version of my [TSConfig Cheat Sheet](https://www.totaltypescript.com/tsconfig-cheat-sheet).

```json
{
  "compilerOptions": {
    /* Base Options: */
    "esModuleInterop": true,
    "skipLibCheck": true,
    "target": "es2022",
    "allowJs": true,
    "resolveJsonModule": true,
    "moduleDetection": "force",
    "isolatedModules": true,
    "verbatimModuleSyntax": true,
    /* Strictness */
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    /* Node Stuff */
    "allowImportingTsExtensions": true,
		"rewriteRelativeImportExtensions": true,
    "module": "NodeNext",
    "noEmit": true,
    /* If your code doesn't run in the DOM: */
    "lib": [
      "es2022"
    ],
  }
}
```

This will likely change in TS 5.8, where the TypeScript team are planning to ship a compatibility flag. Not sure what's in it yet, but it'll make interop with Node's TS support easier.


## Are Enums and Namespaces Supported?

Enums and namespaces are not supported by default. Check out the other features which are not supported [here](https://nodejs.org/api/typescript.html#type-stripping). If you want support for other TS features, you can add `--experimental-transform-types` to make it work.

I'm personally not too sad about this - especially about the [enums](https://www.totaltypescript.com/why-i-dont-like-typescript-enums).

Note that runtime namespaces are not supported, but type-only namespaces (using `declare namespace`) _are_ supported. This is nice - I like type-only namespaces.


## Do I Need To Transpile To JavaScript For Production?

### Node apps

If you're deploying your code to a serverless platform, yes. Transpiling and minifying your code will be key to getting a good cold start.

If you're deploying to a place where cold starts matter less, then probably not! There will be a small cost when the app initially loads your TypeScript (and I do mean small), but once the process is running it's unlikely to cause slowdowns.

One possible wrinkle is if your code dynamically loads other TypeScript files during its processing. I could see that resulting in a little extra slowdown - so tread carefully.

### Libraries

Yes, you still need to transpile your TypeScript to JavaScript before shipping it to NPM. There are two reasons for this:

- So JavaScript users can still consume your library
- TypeScript works faster when consuming declaration files (`.d.ts` files), so not shipping them means you're making your consumers' TS experience slower.

### Monorepos

If you're creating a library in a monorepo, for only that monorepo to consume, I still recommend transpiling your TypeScript files to JavaScript.

The reason is the same as for libraries - the more `.d.ts` files you have in your monorepo, the faster your TS experience will be.

## Will This Come To Previous Versions Of Node?

Yes, TypeScript support will be coming to Node 22, but not Node 20.

[Marco](https://x.com/satanacchio/status/1872426617039114243) mentioned this on X.

TypeScript is coming to Node 23. Let's break down what that means.

Node.js Now Supports TypeScript By Default

Let's talk about another crazy TypeScript trick: `Array[number]`.

```ts twoslash
const roles = ["admin", "editor", "contributor"] as const;

type RolesAsType = typeof roles;

type Role = RolesAsType[number];
//   ^?
```

It looks like absolute insanity.

But I promise by the end of this email, you'll know how it works.

## Extracting Types From Arrays

Let's start with a slightly simpler example.

First, we'll define an array of some fixture data we might use in some tests.

```ts twoslash
const possibleResponses = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
```

We can use `typeof` on `possibleResponses` to extract its type.

We can see that it is an array of objects with a `status` and `body` property.

But what if we want to remove the 'array' part of the type and just get to the object inside?

```ts twoslash
const possibleResponses = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
// ---cut---
type PossibleResponses = typeof possibleResponses;
//   ^?
```

We can use this arcane-looking trick, `Array[number]`, to extract the type of the array.

```ts twoslash
const possibleResponses = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
type PossibleResponses = typeof possibleResponses;

// ---cut---
type PossibleResponse = PossibleResponses[number];
//   ^?
```

Why does this work? What even is this syntax?

## Indexed Access Types

Well, the syntax is an indexed access type. It's the way to access a property on a type.

A simpler version would be to grab a property from an object:

```ts twoslash
type NavbarProps = {
  onChange: () => void;
};

type OnChangeType = NavbarProps["onChange"];
//   ^?
```

By passing `number` to the indexed access type, we're saying "give me all the properties of the object that are accessed with numeric keys".

To demonstrate this, we can create an object with string keys, but a numeric index signature:

```ts twoslash
type ExampleObj = {
  // String keys
  stringKey1: "string-key";
  stringKey2: "string-key";

  // Numeric index signature
  [key: number]: "number-key";
};
```

We can then use `ExampleObj[number]` to extract only the numeric values from the object.

```ts twoslash
type ExampleObj = {
  // String keys
  stringKey1: "string-key";
  stringKey2: "string-key";

  // Numeric index signature
  [key: number]: "number-key";
};

type NumericValuesOnly = ExampleObj[number];
//   ^?
```

## What's The Point?

Keen observers might be looking at this with scepticism. Is this trick really useful?

Surely, you would just create the type _first_, then use it in your application.

No need to extract it from an array.

```ts twoslash
type Response = {
  status: number;
  body: string;
};

const possibleResponses: Response[] = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
```

Well, this trick comes into its own in a few places.

It goes without saying that it's useful in library code.

But it's also great when you're building your own enums from arrays, like in the first example.

```ts twoslash
const roles = ["admin", "editor", "contributor"] as const;

type RolesAsType = typeof roles;

type Role = RolesAsType[number];
//   ^?
```

By the way, this example works because `roles` is marked `as const`, which makes TypeScript infer the literal values of the array.

Without it, TypeScript would infer the type as `string[]`:

```ts twoslash
const roles = ["admin", "editor", "contributor"];

type RolesAsType = typeof roles;

type Role = RolesAsType[number];
//   ^?
```

Deriving types from values is an extremely powerful concept - so much so that I wrote an [entire chapter of my book](https://www.totaltypescript.com/books/total-typescript-essentials/deriving-types) on it.

So, that's `Array[number]` in TypeScript. It extracts all the numeric keys from an object.

In the case of an array, that means it extracts the type of the array member.


Learn how to extract the type of an array element in TypeScript using the powerful `Array[number]` trick.

This Crazy Syntax Lets You Get An Array Element's Type

Learn how to publish a package to npm with a complete setup including, TypeScript, Prettier, Vitest, GitHub Actions, and versioning with Changesets.

How To Create An NPM Package

Let's start with a bit of context. I like enums. I like them a lot. I would really like JavaScript to have them.

But TypeScript's implementation of them is weird enough for me not to recommend them.

## Types Of Enums

You can declare three different types of values for your enums. Numeric, string and inferred:

```ts twoslash
// Numeric
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}

// String
enum PackStatus2 {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

// Inferred
enum PackStatus3 {
  Draft, // Inferred as 0
  Approved, // Inferred as 1
  Shipped, // Inferred as 2
}
```

## Numeric vs String Enums

Numeric and string enums actually behave differently in a couple of ways.

First, how many keys do you think the `PackStatus` object has?

```ts twoslash
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}
```

The answer is 6. Why? Because TypeScript generates both a value-to-key and a key-to-value mapping for numeric enums.

But for string enums, it doesn't do this, so you end up with the expected 3 keys:

```ts twoslash
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}

// [0, "Draft", 1, "Approved", 2, "Shipped"]
console.log(Object.keys(PackStatus));

enum PackStatus2 {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

// ["Draft", "Approved", "Shipped"]
console.log(Object.keys(PackStatus2));
```

They also behave differently when it comes to type-checking.

In places where a string enum is expected, it forces you to pass the enum value:

```ts twoslash
// @errors: 2345
enum PackStatus {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

logStatus(PackStatus.Draft);

// Errors, correctly!
logStatus("Draft");
```

But with numeric enums, you can pass a raw number in places where the enum is expected. What?

```ts twoslash
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

logStatus(PackStatus.Draft);

// No error. WHAT?
logStatus(0);
```

Hilariously, you can even mix and match numeric and string values in the same enum.

Don't do this.

```ts twoslash
enum PackStatus {
  Draft = "Draft",
  Approved = 2,
  Shipped, // Inferred as 3
}
```

## Nominal Typing

My final frustration with enums is fairly subjective.

I like my TypeScript to be just JavaScript with types. Enums feel like they break that rule.

For example, you can't use an enum in place of another enum, even if the values are the same:

```ts twoslash
// @errors: 2345
enum PackStatus {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

enum PackStatus2 {
  Draft = "Draft",
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

// Errors, even though the values are the same
logStatus(PackStatus2.Draft);
```

EVEN if the second enum is just a reference to the first enum.

```ts twoslash
// @errors: 2345
enum PackStatus {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

// ---cut---
enum PackStatus2 {
  Draft = PackStatus.Draft,
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

// Errors, even though the values are the same
logStatus(PackStatus2.Draft);
```

There are currently [71 issues marked as bugs](https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+enum+label%3Abug) related to enums in the TypeScript repo.

I've heard hints from the TS team that many of these are uncloseable due to the way enums are implemented.

## Conclusion

If I saw an enum in a codebase, I'm unlikely to get rid of it. If it's using inferred values, I'll probably add them explicitly.

But I wouldn't add an enum to a fresh codebase.

If you're desperate to use enums, I'd strongly recommend using string enums only.

They're explicit, behave more like enums, and look more like their transpiled code.

And if you want to see what I use instead of enums, check out [this section of my book](https://www.totaltypescript.com/books/total-typescript-essentials/deriving-types#using-as-const-for-javascript-style-enums).


Enums in TypeScript can be confusing, with differences between numeric and string enums causing unexpected behaviors.

Why I Don't Like Enums

A common refrain in the web development discourse is that TypeScript is 'just a linter for JavaScript'. It's an oddly multifaceted phrase. It can be used to disdain TypeScript as a 'mere' linter, or to praise it for its simplicity.

I want to give this statement the attention it deserves. Is TypeScript just a linter? No, but yes.

## TypeScript Is Just JavaScript

TypeScript is the most successful attempt ever to create a meta-language for JavaScript. It's JavaScript's tastiest flavor. Milder than CoffeeScript. Sweeter than ClojureScript.

Part of its success is its fidelity to JavaScript. It clings tightly to it. Since enums, TypeScript has added zero new runtime features not already present in JavaScript. Its early attempts to add runtime features are now [falling out of fashion](/books/total-typescript-essentials/typescript-only-features#when-to-prefer-es-vs-ts). These days, TypeScript concerns itself with typing JavaScript.

TypeScript requires far fewer annotations than most typed languages. It can [infer](/books/total-typescript-essentials/essential-types-and-annotations#type-inference) a great deal just by looking at your code. So your JavaScript outputs often look identical to your TypeScript inputs, but with the types stripped out.

Unmask TypeScript, and you'll find JavaScript. The space between them is thin. This is a good thing.

I've been curious about the more refined flavors of JavaScript for a while now. [Elm](https://elm-lang.org/) and [ReScript](https://rescript-lang.org/) especially. But betting company code on these languages feels risky. There are a lot more JavaScript developers than Elm developers. And TypeScript is just a linter for JavaScript.

## Is TypeScript "Strongly Typed"?

But TypeScript is not just a linter for JavaScript. According to its own [landing page](https://www.typescriptlang.org/), it is a 'strongly typed programming language'. This assertion feels controversial, and I've seen 'TypeScript is a linter' used in rebuttal. "TypeScript is just JavaScript with some types added, not a language by itself".

TypeScript certainly has some types. Basic types. Object types. Types for the DOM. But there's one type that calls the rest into question: [`any`](https://www.totaltypescript.com/books/total-typescript-essentials/essential-types-and-annotations#the-any-type).

`any` breaks the rules. It's a nuclear warhead against rock, paper, scissors. It can infect a codebase, metastasizing from a single function. Its mere presence in the language means, in my eyes, TypeScript cannot be considered 'strongly typed'. There are no guarantees. The center cannot hold.

`any` has to exist. If it didn't, TypeScript would be burdened with the challenge of describing the entirety of JavaScript in types. `any` is a pressure valve. It makes TypeScript simpler and leaner. I'm glad it exists.

But `any` is a virus that remakes its host. TypeScript's types are at best advisory. Guidelines, not rules. You can disable its checking at any time. TypeScript is just a linter for JavaScript.

## TypeScript Is Just A Linter

Let's state the obvious. TypeScript is not just a linter. It's an astonishingly advanced type system. It's a compiler. It's a language server that can run on any compatible IDE.

But thinking of it _like_ a linter is useful. Its type system lives to serve JavaScript. It's easy to adopt. It's easy to eject from. If you don't understand it, shut it up and move on.

And embrace it. You're not a TypeScript dev. You're a JavaScript dev. `typeof NaN` is a number and `typeof null` is an object. You'll get more out of TypeScript as a result.


Is TypeScript just a linter? No, but yes.

Is TypeScript Just A Linter?

Today is the biggest ship day of my life. After 11 months of work, I'm launching:

- Total TypeScript Essentials: a 16-chapter [TypeScript book](https://www.totaltypescript.com/books/total-typescript-essentials), for FREE.
- [Pro Essentials](https://www.totaltypescript.com/workshops/typescript-pro-essentials): a new, 200-exercise course for $200.
- A giveaway worth ~$80,000 to existing customers.
- A huge price cut on Total TypeScript.
- A 20% sale until Friday.

Here's the full story:

## The Book - Total TypeScript: Essentials

My book, [Total TypeScript: Essentials](https://www.totaltypescript.com/books/total-typescript-essentials), is finally ready.

It's been 11 months of work. 16 chapters. Hundreds of pages. And it's free.

It covers everything you need to get a job with TypeScript, from setting up your IDE to understanding generics.

And it's 100% freely available on Total TypeScript. Forever.

We'll also be releasing this as a printed book! You can pre-order a copy on [No Starch's site](https://nostarch.com/total-typescript).

## The Course - Pro Essentials

We're also releasing a new course, [Pro Essentials](https://www.totaltypescript.com/workshops/typescript-pro-essentials).

It's the ultimate TypeScript masterclass - the no-brainer training programme to help your team build TypeScript apps.

It contains over 200 exercises and requires no TypeScript experience.

And, until Friday, it's $200.

Pro Essentials is different from everything else I've shipped.

Before, I focused on advanced content to turn you into a TS wizard. The content in the [Core Volume](https://www.totaltypescript.com/workshops) is perfect for this.

But with Essentials (the book) and Pro Essentials (the course), I want Total TypeScript to be the default choice for teams.

Got a team transitioning to TS? Get them Pro Essentials, at $200 a pop (cheaper in bulk) and you'll have some happy engineers working at max capacity.

## Price Cut and Giveaway

We've slashed the price of Total TypeScript. You can now pick up the entire of TT, including Pro Essentials, for $500.

And until Friday, it's 20% off: $400.

This is a HUGE drop from where it was before.

What about the folks that already paid the higher price for the existing workshops?

Existing TT customers will get Pro Essentials for free. Over all our customers, that's around $80,000 of giveaway.

I'm so excited to finally share this with you. I hope you enjoy it as much as I enjoyed creating it.


It's a massive ship day. We're launching a free TypeScript book, new course, giveaway, price cut, and sale.