# `@sister.software/tsconfig`

The TypeScript configuration used by Sister Software. Three flavors, one shared base.

While it is possible to use this configuration outside of our projects, you may find that it is not
as useful as other popular configurations.

## Usage

```jsonc
// A package that runs on Node.
{ "extends": "@sister.software/tsconfig/node" }
```

```jsonc
// A package that runs in a browser.
{ "extends": "@sister.software/tsconfig/web" }
```

```jsonc
// A package that is neither — pure logic with no runtime globals.
{ "extends": "@sister.software/tsconfig" }
```

| Entry point | Adds to the base                                                  |
| ----------- | ----------------------------------------------------------------- |
| `.`         | nothing — strict, `nodenext`, `lib: ["ESNext"]`, no ambient types  |
| `./node`    | `types: ["node"]`                                                  |
| `./web`     | `lib: ["ESNext", "DOM", "DOM.Iterable"]`, `types: []`, `react-jsx` |

Pick by what the code _runs on_, not by what builds it. A browser package whose build scripts use
Node still extends `/web`; those scripts are excluded from the project.

### Why `./web` sets `types: []`

An absent `types` auto-includes every `@types` package in `node_modules`. In a monorepo that hands a
browser package the whole tooling surface, so Node's globals resolve in code that will never see
them. Empty means "nothing ambient" — add what you need explicitly.

### Compatibility

Subpath resolution for `extends` needs **TypeScript 5.0+**, which is when `extends` began resolving
through a package's `exports` map. `main` still points at the neutral config, so older TypeScript
resolves the bare specifier as it always did — it just cannot reach `/node` or `/web`.