Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable project references by upgrading TypeScript to >3.6 #7807

Closed
sampsakuronen opened this issue Oct 11, 2019 · 5 comments
Closed

Enable project references by upgrading TypeScript to >3.6 #7807

sampsakuronen opened this issue Oct 11, 2019 · 5 comments

Comments

@sampsakuronen
Copy link

sampsakuronen commented Oct 11, 2019

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:

  • Share types between backend and frontend
  • Share common utilities between different frontend apps

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.

Quote from Typescript 3.6 release announcement:

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.

@ianschmitz
Copy link
Contributor

ianschmitz commented Oct 11, 2019

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.

@Bnaya
Copy link

Bnaya commented Oct 20, 2019

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] (TypeStrong/fork-ts-checker-webpack-plugin#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

// Process any JS outside of the app with Babel.
// Unlike the application JS, we only compile the standard ES features.
{
test: /\.(js|mjs)$/,
exclude: /@babel(?:\/|\\{1,2})runtime/,
loader: require.resolve('babel-loader'),
options: {
babelrc: false,
configFile: false,
compact: false,
presets: [
[
require.resolve('babel-preset-react-app/dependencies'),
{ helpers: true },
],
],

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:

  1. Make the main file "main": "src/index" without suffix. and avoiding using dist
  2. Add special field in the package.json, say, "typeScriptSrc": "src/index.ts" and configure webpack to also look for it
  3. Add a webpack plugin with similar resolving logic as tsc has

@Bnaya
Copy link

Bnaya commented Oct 20, 2019

I've created an example how it can be done:
https://github.com/Bnaya/ts-composite-babel-loader-webpack

@Bessonov
Copy link

Bessonov commented Dec 8, 2019

Duplicate of #6799

@ianschmitz
Copy link
Contributor

Closing in favor of existing issue.

@lock lock bot locked and limited conversation to collaborators May 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants