Incremental Builds - jeffsim/typescriptGulpSample GitHub Wiki
TODO: This section
- What not to do: gulp-changed-in-place
- This is what I naively started with.
- Works great in lot of situations; but not a typescript one
- Reason: typescript compiler needs all .ts files, not just changed ones
- What to do instead: two things:
- Using gulp.watch for file-level modification checking
- How it works: always-running task keeps state between builds, allowing it to maintain some info between runs. What info? It's magic!
- What you get: file-level checks. ~15% perf improvement in this sample, likely more in 'real' projects (the claim is 50% reduction in compile time)
- Using project-level modification checking
- Only applies if your project is like this one and has multiple contained projects; dependencies between them okay
- If it does apply, then you can see massive compilation improvements here. My duality project has about 200 .ts files in it, and being able to iteratively develop a sample without having to recompile the editor, plugins, and tests everytime is ridiculously nice (e.g. cuts a 30 second build time down to < 1 second!)
- How it works
- Maintains project-level modifiedFilesCache and tracks last modified times
- Of note: using gulp.src().dest() works for copying a file, but it updates the last modified time in the process, which breaks how project-level incremental builds work. Gulp-preserve-time to the rescue!
- Building and bundling
- Basically the same as Project building and bundling, except there's no project to track bundle, so the bundle's cache is instead tracked in bundle.modifiedCache.
- Maintains project-level modifiedFilesCache and tracks last modified times
- Using gulp.watch for file-level modification checking
- Other options:
- IsolatedModules. Why not here? Include links from comment
- Settings
- incrementalBuild
- recompiledOnDTSChanges