@codecompose/typescript-config 3.0.0-0 → 3.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +40 -39
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,16 +1,16 @@
|
|
|
1
1
|
# typescript-config
|
|
2
2
|
|
|
3
|
-
Opinionated and reusable
|
|
3
|
+
Opinionated and reusable TypeScript configurations, geared towards modern build tooling in both monorepos and single repositories.
|
|
4
4
|
|
|
5
|
-
-
|
|
6
|
-
-
|
|
5
|
+
- Uses the TypeScript compiler for type-checking only (*)
|
|
6
|
+
- Assumes your bundler outputs code, sourcemaps, and type declarations (*)
|
|
7
7
|
- Requires TypeScript 6.0 or later
|
|
8
8
|
- Builds on TS6 strict defaults with additional strictness: `noUncheckedIndexedAccess`, `noImplicitOverride`, and `erasableSyntaxOnly`
|
|
9
|
-
-
|
|
10
|
-
-
|
|
11
|
-
- Uses `${configDir}`
|
|
9
|
+
- Assumes `src` and `dist` directories
|
|
10
|
+
- Provides `~/` and `@/` path aliases for `src`
|
|
11
|
+
- Uses `${configDir}` for zero per-project configuration
|
|
12
12
|
|
|
13
|
-
(*)
|
|
13
|
+
(*) The shared-library and shared-react-library configs are an exception: they enable `composite`, `declaration`, and `declarationMap` because project references require TypeScript to emit declarations. Your bundler still handles the JavaScript output.
|
|
14
14
|
|
|
15
15
|
To use this successfully, you would need a modern bundler like [tsdown](https://tsdown.dev/). You can check out the [typescript-monorepo](https://github.com/0x80/typescript-monorepo) boilerplate for a working example of a modern monorepo setup with tsdown.
|
|
16
16
|
|
|
@@ -33,7 +33,7 @@ Often, no configuration is needed apart from `extends`.
|
|
|
33
33
|
|
|
34
34
|
## Available Configurations
|
|
35
35
|
|
|
36
|
-
- `base` -
|
|
36
|
+
- `base` - Anything non-specific
|
|
37
37
|
- `library` - Standalone libraries (not part of a monorepo)
|
|
38
38
|
- `shared-library` - Shared libraries in a monorepo
|
|
39
39
|
- `react-library` - Standalone React component libraries (not part of a monorepo)
|
|
@@ -44,36 +44,6 @@ Often, no configuration is needed apart from `extends`.
|
|
|
44
44
|
|
|
45
45
|
For other project types, like a CLI or E2E app, you can use the `base` configuration.
|
|
46
46
|
|
|
47
|
-
## Assuming Bundler Output
|
|
48
|
-
|
|
49
|
-
Outputs like sourcemaps and type declarations are disabled because it is assumed that your bundler will handle that.
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
## Incremental Builds
|
|
53
|
-
|
|
54
|
-
All configurations have `incremental` set to `true`. In my experience, it can
|
|
55
|
-
happen that builds get stuck in limbo, and you need to delete the
|
|
56
|
-
`tsconfig.tsbuildinfo` file to get things going again. For this reason, I
|
|
57
|
-
recommend adding the following script to your manifest based on `del-cli`:
|
|
58
|
-
|
|
59
|
-
`"clean": "del-cli dist tsconfig.tsbuildinfo"`
|
|
60
|
-
|
|
61
|
-
## Project References
|
|
62
|
-
|
|
63
|
-
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.
|
|
64
|
-
|
|
65
|
-
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.
|
|
66
|
-
|
|
67
|
-
Without project references, the consuming code would only see the `dist` output of the shared package.
|
|
68
|
-
|
|
69
|
-
If you prefer to work without project references, you should set your bundler to also [output declaration maps](https://tsdown.dev/options/dts#declaration-map), but not all bundlers can do this.
|
|
70
|
-
|
|
71
|
-
## Publishing to NPM
|
|
72
|
-
|
|
73
|
-
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.
|
|
74
|
-
|
|
75
|
-
To export source files next to your dist output, you define the `files` field in your package.json as `["src", "dist"]`.
|
|
76
|
-
|
|
77
47
|
## V3 — TypeScript 6
|
|
78
48
|
|
|
79
49
|
V3 is a major release that requires TypeScript 6.0 or later.
|
|
@@ -104,7 +74,38 @@ For users upgrading from v2, see the migration guide below.
|
|
|
104
74
|
- **Removed commented-out `baseUrl`** — deprecated in TS6
|
|
105
75
|
- **Action required:** if you relied on auto-included `@types/*` packages, add `"types": ["node"]` (or whatever types you need) to your tsconfig
|
|
106
76
|
|
|
77
|
+
## Assuming Bundler Output
|
|
78
|
+
|
|
79
|
+
Outputs like sourcemaps and type declarations are disabled because it is assumed that your bundler will handle that. The shared-library and shared-react-library configs are an exception — they enable `declaration` and `declarationMap` because `composite` mode requires it for project references to work.
|
|
80
|
+
|
|
81
|
+
## Incremental Builds
|
|
82
|
+
|
|
83
|
+
All configurations have `incremental` set to `true`. In my experience, it can
|
|
84
|
+
happen that builds get stuck in limbo, and you need to delete the
|
|
85
|
+
`tsconfig.tsbuildinfo` file to get things going again. For this reason, I
|
|
86
|
+
recommend adding the following script to your manifest based on `del-cli`:
|
|
87
|
+
|
|
88
|
+
`"clean": "del-cli dist tsconfig.tsbuildinfo"`
|
|
89
|
+
|
|
90
|
+
## Project References
|
|
91
|
+
|
|
92
|
+
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.
|
|
93
|
+
|
|
94
|
+
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.
|
|
95
|
+
|
|
96
|
+
Without project references, the consuming code would only see the `dist` output of the shared package.
|
|
97
|
+
|
|
98
|
+
If you prefer to work without project references, you should set your bundler to also [output declaration maps](https://tsdown.dev/options/dts#declaration-map), but not all bundlers can do this.
|
|
99
|
+
|
|
100
|
+
## Publishing to NPM
|
|
101
|
+
|
|
102
|
+
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.
|
|
103
|
+
|
|
104
|
+
To export source files next to your dist output, you define the `files` field in your package.json as `["src", "dist"]`.
|
|
105
|
+
|
|
107
106
|
## Caveats
|
|
108
107
|
|
|
109
|
-
Next.js v15 requires you to explicitly configure
|
|
108
|
+
Next.js v15 requires you to explicitly configure `include`. If you give it just "src" it will inject its own types on startup. I assume this will improve in the future.
|
|
109
|
+
|
|
110
|
+
The base configuration includes `"${configDir}/src/**/*.json"` alongside `"${configDir}/src"` because TypeScript's `include` only picks up supported extensions (`.ts`, `.tsx`, etc.) when given a directory path. If you override `include` in your project tsconfig, make sure to keep the JSON glob if you import JSON files.
|
|
110
111
|
|