Here's a method for how to exclude typings files from dependencies when compiling TypeScript projects.



## Install a problem dependency

The problem comes when we install a dependency into our already-TypeScript project that has other typings that mess up the project we're in.

For example, I was working on a [hyperapp](https://github.com/hyperapp) TypeScript project and installed a new dependency.  Upon my next `tsc`, I suddenly had hundreds of errors similar to this:

```
error TS2605: JSX element type 'VNode<Props> | null' is not a constructor function for JSX elements.
```

When it went to type-check my code, TypeScript thought React was in charge of JSX and thus wasn't compatible with my Hyperapp components. 

I found out that there were new React typings by running:

```
npm ls @types/react
```

Sure enough, down in the subdependencies, something else was shipping with `@types/react`.  To fix this, I wanted to keep the new dependency but ignore those typings.

## Exclude doesn't work

My first adjustment to the long list of potential `tsconfig.json` configurables was [`exclude`](https://www.typescriptlang.org/tsconfig#exclude). This seemed to match the verb of what I was trying to do. But apparently it ignores `@types` directories in its exclusion. They're special. 

Blacklisting what I wanted to ignore seemed out, so I looked for the whitelist

## Whitelist with types and typeRoots

The two whitelist options that appear are [`types`](https://www.typescriptlang.org/tsconfig#types) and [`typeRoots`](https://www.typescriptlang.org/tsconfig#typeRoots). 

By default, all `@types` available to node module resolution (include those in parent directories) and available and used when type checking. `types` will whitelist override that by file (package name). `typeRoots` will override that by directory.

## Process to whitelist

My process to whitelist down to the correct types list was to:

1. Set `types` to an empty array in `tsconfig.json`:

```json
{
  "compilerOptions": {
    "types": []
  }
}
```

2. Run `tsc` multiple times and interpret each class of type errors.

For instance, I ran once and got errors like:

```
error TS2304: Cannot find name 'expect'.
```

This came from a spec file and I use jest, so I added the `jest` type.  The next `tsc` produced:

```
error TS2951: Cannot find name 'require'
```

It was even prompting me to install `node` types.  So, my fixed up `tsconfig.json` looked like this in the end:

```json
{
  "compilerOptions": {
    "types": ["jest", "node"]
  }
}
```

And `tsc` was happy with no errors.

How else have you solved this problem and ignored the types that install dependencies puts into your projects?

How to exclude typings files from dependencies when compiling TypeScript projects.

Ignore Dependency Types in Typescript

If you narrow an interface in Typescript, you can operate on it more specifically.  And you can keep your type safety.



## Multiple Types

Narrowing types requires first the challenge of having two or more types.  Let's say you have two interfaces:

```typescript
interface Legacy {
  render(): void
}

interface Current {
  update(): void
}
```

In this scenario, these two types represent the same kind of thing.  It's a program -- either a legacy version or the current version.  They have different APIs.  One's an object with a `render` function, the other with an `update`.  So, let's define them as related:


```typescript
type Program = 
  | Legacy
  | Current
```

Now we have a challenge to deal with.

## Distinguishing Types

In our code, we want to use the programs similarly, whether it's the legacy or current version.  So, let's say we have a function:

```typescript
function run(program: Program) {
  if (isLegacy(program)) 
    program.render()
  else 
    program.update()
}
```

Either version of the program will run, but they're kicked off with a different API.  

So, the magic question is: What's inside the `isLegacy` function that allows TypeScript to keep us type safe?

## Narrowing Types with a Type Predicate

`isLegacy` must know how to narrow the types.  We *narrow* in on which version of type `Program` it really is.  It's not enough to know that it's a `Program`; that's too broad.  We need to know if it's specifically `Legacy` or `Current`.

Here's an example implementation of `isLegacy` and how this might be done:

```typescript
function isLegacy(program: Program): program is Legacy { 
  return (program as Legacy).render !== undefined 
}
```

There's a lot of typing happening here.  Here are the important points:

- The input is the union type, `Program`.  Coming in, `program` could be either version.
- The return type is a *type predicate* (`program is Legacy`). The name `program` matches the function parameter name, followed by the `is` keyword.
- Internally, program is cast `as Legacy` so the TypeScript typechecker can be happy with `.render` being called on it.

And remember how this was used:

```typescript
  if (isLegacy(program))
    program.render()
```

Inside that conditional, after the true evaluation of `isLegacy`, calling functions that are only available on the `Legacy` version of the program is safe.

## Narrowing Types with the `in` Keyword

There's another way that type narrowing is possible.  Instead of using the type predicate, we could use the `in` keyword, testing for the existence of the distinguishing property.  

Only the `Legacy` version of `Program` has a `render` function, so we'll test for it:

```typescript
  if ("render" in program)
    program.render()
```

The nice thing about this method is that it's a little terser and not so much typing in the syntax.

What other ways have you used to narrow types in your TypeScript programs?

If you narrow an interface in Typescript, you can operate on it more specifically.