typescript-config

Opinionated and reusable Typescript configurations, geared towards modern build tooling in both monorepos and single repositories.

• Only use the Typescript compiler for type-checking (*)
• Use your bundler to output code, sourcemaps, and type declarations where needed.
• Use strict settings, including noUncheckedIndexedAccess and erasableSyntaxOnly.
• Assume src and dist directories
• Use of ~/ or @/ as path alias for src
• Leverages TS 5.5 feature ${configDir} to remove all client configuration.

(*) Project references / shared monorepo packages also emit code.

To use this successfully, you would need a modern bundler like tsdown. You can check out the mono-ts boilerplate for a working example of a modern monorepo setup with tsdown.

Install

npm i @codecompose/typescript-config -D

Usage

{
  "extends": "@codecompose/typescript-config/base"
}

Often, no configuration is needed apart from extends.

Available Configurations

• base - Anything non-specific
• library - Standalone libraries (not part of a monorepo)
• shared-library - Shared libraries in a monorepo
• react-library - Standalone React component libraries (not part of a monorepo)
• shared-react-library - Shared React component libraries in a monorepo
• nextjs - Next.js applications
• service - A backend service like an API server or cloud function

For other project types, like a CLI or E2E app, you can use the base configuration.

Assuming Bundler Output

Outputs like sourcemaps and type declarations are disabled because it is assumed that your bundler will handle that.

Incremental Builds

All configurations have incremental set to true. In my experience, it can happen that builds get stuck in limbo, and you need to delete the tsconfig.tsbuildinfo file to get things going again. For this reason, I recommend adding the following script to your manifest based on del-cli:

"clean": "del-cli dist tsconfig.tsbuildinfo"

Project References

The shared-library and shared-react-library configurations have composite set to true. This is required for Typescript "project references" to work in a monorepo. They provide IDE go-to-definition, without having to emit the module output.

In practice, this means that if you alter code in a shared package, the consuming app or library will pick up the changes, without requiring a watch task on the shared package to trigger a rebuild on every change.

Without project references, the consuming code would only see the dist output of the shared package.

If you prefer to work without project references, you should set your bundler to also output declaration maps, but not all bundlers can do this.

Publishing to NPM

If you publish your package, it is recommended to include the Typescript source and type declaration maps. This allows the consumer to jump straight to the source code, which is great for overall readability and learning.

To export source files next to your dist output, you define the files field in your package.json as ["src", "dist"].

Caveats

Older tooling might not correctly interpret the use of ${configDir}, which this package uses extensively, and was only introduced in TS v5.5.

Next.js v15 requires you to explicitly configure "includes". If you give it just "src" it will inject its own types on startup. I assume this will improve in the future.