Cannot use `composite` tsconfig.json setting

[osdiab]

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes

Which terms did you search for in User Guide?

typescript composite isolatedModules

Environment

  System:    OS: macOS 10.14.2
    CPU: (4) x64 Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz
  Binaries:
    Node: 11.4.0 - ~/.nvm/versions/node/v11.4.0/bin/node
    Yarn: 1.16.0 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v11.4.0/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
    Safari: Not Found
  npmPackages:
    react: Not Found
    react-dom: Not Found
    react-scripts: Not Found
  npmGlobalPackages:
    create-react-app: Not Found

Steps to Reproduce

1. Run yarn create react-app my-app --typescript
2. add composite: true to tsconfig.json
3. run yarn start, get Option 'composite' cannot be specified with option 'isolatedModules'. TS5053
4. Remove isolatedModules line from tsconfig
5. run yarn start, create-react-app re-adds isolatedModules and you get the same error

Expected Behavior

I could use the composite flag

Actual Behavior

I can't use the composite flag

Reproducible Demo

Above steps will reproduce this, pretty trivial.

This is potentially equally as much a typescript issue, though this is not really big to me—i just want to be able to build all my packages in my monorepo in one command, rather than having a separate invocation of tsc --build for my website package. But thought I'd log the issue here.

[bfricka]

This is not a bug report, it's a feature request. Using CRA + TS for anything but the most basic project setup is not supported currently. For composite projects in particular, there really isn't much support in Webpack at all ATM (@ts-tools/webpack-loader, ts-loader, awesome-typescript-loader, etc.). It's a complicated feature and no one has done the work to properly integrate it yet. So unless you're using tsc, you're out of luck.

Some other loaders can handle more complicated setups. E.g. @ts-tools/webpack-loader can do monorepos, but it has it's own drawbacks that make it problematic (e.g. doesn't play nice w/ downstream loaders).

It's all a bit of a clustf*ck at this point and I'm hoping the TS build landscape looks a bit better in the next year.

[osdiab]

I'm finding in my CRA project that uses tsc -b to reference other shared modules, that it seems to be incorporated into the CRA build just fine - I'll try to make a simple repo that demonstrates it, but both my development server and output production app seem to work fully with project references in a Yarn monorepo. Though maybe I'm missing the incompatibility you're speaking of.

Though yes, I agree that it's a pretty hairy system at the moment.

[bfricka]

@osdiab The monorepo issue occurs with nested linked imports:

Say you have monorepo, with modules a, b, c

a imports b and/or c works fine.
a imports b imports c, does not work (cannot find module c). Even though, a can import c, if b imports c, the module resolution doesn't know how to handle it.

ts-tools/webpack-loader handles this by parsing multiple config files as required.

I'm still trying to find a way to make this work w/ CRA that isn't nasty. E.g. I've setup a sample monorepo that demonstrates the issue. The current roadblock is that babel-loader rule limits include to appSrc. If you instead try to pass an array, you'll get errors from modules.js, which does a dumb parse of tsconfig.json / jsconfig.json, and tells you that you cannot set your baseUrl to something outside src.

To get to this point I use typescript to parse the config file properly (ts.readJsonConfigFile, ts.parseJsonSourceFileConfigFileContent), which then derives the baseUrl properly from the project root (b/c this parsing actually handles "extends", instead of just JSON.parse and pulling out compilerOptions).

I've had to move on to other stuff for a bit, but I'll come back to this to figure out why this is the case and if I can work around it.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[tommedema]

This is still an issue and should not be closed

[matyasfodor]

I am also looking for a solution to this issue. Current workaround: npm link the shared lib. Drawback: you need to manually compile the lib every time the code changes.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[tommedema]

This is still an issue and should not be closed

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[matyasfodor]

This is still an issue, and would really like if this could be solved 🙏 !