TypeScript project references have been available since 3.0. The newest TypeScript (since 3.6) brought APIs exposing this feature. For those unfamiliar with the concept please see this great example project.
Enabling this functionality would greatly improve the way we can share code amongst different apps. It should also increase the build speed as we would have access to incremental builds.
Our use cases would include:
Currently tsc --build isn't compatible because it conflicts with some opinions that create-react-app has (e.g. isolatedModules). EDIT: as @ianschmitz pointed out below this opinion actually comes from babel-plugin-transform-typescript.
APIs to Support --build and --incremental
TypeScript 3.0 introduced support for referencing other projects and building them incrementally using the --build flag. Additionally, TypeScript 3.4 introduced the --incremental flag for saving information about previous compilations to only rebuild certain files. These flags were incredibly useful for structuring projects more flexibly and speeding builds up. Unfortunately, using these flags didn’t work with 3rd party build tools like Gulp and Webpack. TypeScript 3.6 now exposes two sets of APIs to operate on project references and incremental program building.
For creating --incremental builds, users can leverage the createIncrementalProgram and createIncrementalCompilerHost APIs. Users can also re-hydrate old program instances from .tsbuildinfo files generated by this API using the newly exposed readBuilderProgram function, which is only meant to be used as for creating new programs (i.e. you can’t modify the returned instance – it’s only meant to be used for the oldProgram parameter in other create*Program functions).
For leveraging project references, a new createSolutionBuilder function has been exposed, which returns an instance of the new type SolutionBuilder.
With regards to isolatedModules, it's not an opinion of ours, rather a restriction by the tool chain we use (see https://babeljs.io/docs/en/babel-plugin-transform-typescript#typescript-compiler-options).
I'm all for supporting this, but it needs to be supported by our existing tool chain (webpack, babel, jest, fork-ts-checker-webpack-plugin, etc) via updated configuration or otherwise.
project references + isolatedModules will be possible from typescript 3.7
Lets put aside fork-ts-checker-webpack-plugin [that has an open issue for it] (https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/issues/328)
until then, for typecheck, you can always run it independently, and have the IDE integration.
Other problems and possible workarounds:
CRA use babel and not tsc to build typescript.
Babel/babel-loader don't have the notion of references. it dons't read any value from tsconfig.json
But we don't need it to!
What we need is webpack to pick the .ts files and pass them to babel-loader.
So we need to make
https://github.com/facebook/create-react-app/blob/09cbb89d44773c77b9197e864bbafb80bd853098/packages/react-scripts/config/webpack.config.js#L460-L475
access also TypeScript
package.json.main issue:
If the packages are not indented to be published, its very simple to just set the main field in the package.json to the .ts file
But if the packages are suppose to be also published, A problem can be when there's a package with "main": "index.js" or "main": "dist/index"
While the source is index.ts or src/index.ts
tsc knows to trace back to the original typescript sources, but webpack, without our help, will look for dist/index and will fail.
3 possible workarounds:
"main": "src/index" without suffix. and avoiding using dist"typeScriptSrc": "src/index.ts" and configure webpack to also look for itI've created an example how it can be done:
https://github.com/Bnaya/ts-composite-babel-loader-webpack
Closing in favor of existing issue.
Most helpful comment
project references + isolatedModules will be possible from typescript 3.7
Lets put aside fork-ts-checker-webpack-plugin [that has an open issue for it] (https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/issues/328)
until then, for typecheck, you can always run it independently, and have the IDE integration.
Other problems and possible workarounds:
CRA use babel and not tsc to build typescript.
Babel/babel-loader don't have the notion of references. it dons't read any value from
tsconfig.jsonBut we don't need it to!
What we need is webpack to pick the .ts files and pass them to babel-loader.
So we need to make
https://github.com/facebook/create-react-app/blob/09cbb89d44773c77b9197e864bbafb80bd853098/packages/react-scripts/config/webpack.config.js#L460-L475
access also TypeScript
package.json.main issue:
If the packages are not indented to be published, its very simple to just set the main field in the package.json to the .ts file
But if the packages are suppose to be also published, A problem can be when there's a package with
"main": "index.js"or"main": "dist/index"While the source is
index.tsorsrc/index.tstscknows to trace back to the original typescript sources, but webpack, without our help, will look fordist/indexand will fail.3 possible workarounds:
"main": "src/index"without suffix. and avoiding usingdist"typeScriptSrc": "src/index.ts"and configure webpack to also look for it