This project is no longer maintained. Please use tsc project mode - it should now be mature enough to work well in most situations. Alternatively, use turborepo which has pretty good caching for any sort of command:
Experimental caching TypeScript compiler suitable for monorepos and CI.
This acts as a drop-in replacement for TypeScript's own tsc. It will store the compiled files in a cache directory at $CTSC_CACHE_DIR (default to /tmp/ctsc). The next time the compiler is invoked for a particular module, the cached output will be re-used if all the inputs are the same (checked with git hash-object, sha1).
With the introduction of project mode, local caching was added, however, it has 3 significant restrictions:
- it requires that all modules compile with declarations. This means that the toplevel application packages cannot easily be included in the project mode and have to be compiled separately.
- it requires you to specify the dependant projects, even though they can be read from
package.json. This means double book-keeping. - it only reuses files found in the local directory. This means it cannot be used to speed up compilation in CI by having a shared cache directory containing most of the unchanged modules, precompiled.
ctsc has a different set of limitations, which are somewhat less restrictive:
- it requires the
outDirsetting, so it can more easily cache the output directory properly. This limitation may be removable in the future if we decide to add a filter of the files to copy, as well as use a better copying solution such asrsyncorcpx(slow) - it requires the
includesetting, so it can more easily read all the inputs. This limitation may also be removable in the future if we decide to add a filter on the files to use when calculating the input hash.
Most monorepo projects already specify an outDir as build and include directories (e.g. src,
tests, etc) so we believe these limitations are ok. Let us know if you disagree.
yarn add ctsc
Requirements:
- (windows): WSL - windows subsystem for linux (find, xargs, tail)
- git (for
git hash-object)
Within a package dir:
ctsc [-p tsconfig.json]
The package must have at least the following configuration in tsconfig:
- include - must be an array of directories or files to include
- compilerOptions.outDir - must exist and be a target output directory
and its workspace dependencies must be referenced in package.json dependencies or
devDependencies
Then you can use it with wsrun
yarn wsrun --staged -r ctsc
To prune old items from the cache (use env var CTSC_TMP_MAX_ITEMS to limit the cache size)
ctsc --clean
To purge the entire cache
ctsc --purge
- ctsc calculates two types of hash: input files hash IHASH, and output (type) hash, OHASH
- When ctsc is used to build the package
Bfor the first time, a.ctsc.hashfile is inserted into the output, containing theOHASH- a hash computed from all the outout .d.ts files produced by the compilation. - If package
A's dependency isB, the OHASH ofBfrom its.ctsc.hashfile is included when calculating the input hashIHASHhash of packageA. In addition, all the sources specified inincludeare also considered when calculating the IHASH. - If this input hash matches a directory in
$CTSC_CACHE_DIRnamed$IHASH,tscis not invoked. Instead, the outDir is copied from the cache directly to the destination. - With this scheme, if a depedency has a change in its type definitions, it will propagate a rebuild to all its dependants. If the package doesn't have a types change, a rebuild will not propagate.
- If the dependants themselves end up with a type definition change, rebuild propagation will continue further.
Yes! If the dependency was compiled with ctsc, a .ctsc.hash will be included in the output directory. If this hash of the definition files has changed, any module that depends on that dependency will be rebuilt by ctsc when you install the new version via yarn/npm!