Type checking failure when building in-repo addons with project references

[hmajoros]

Please paste the output of ember -v here

ember-cli: 3.28.0
node: 14.15.1
os: darwin x64

Please paste the output of tsc -v here

Version 4.4.2

Please paste the version of ember-cli-typescript and ember-cli-typescript-blueprints here

[email protected]

no blueprints

Please paste your tsconfig.json and tslint.json or eslint.json (if applicable) below

top level tsconfig nested tsconfig

What are instructions we can follow to reproduce the issue?

git clone [email protected]:brendenpalmer/ember-cli-typescript-typechecking-repro.git
cd ember-cli-typescript-typechecking-repro
yarn
cd packages/ts-addon/
ember b

typechecking should fail with the above steps, running ember build from inside ts-addon. This repo make use of composite projects & in this particular case, the ts compiler fails to build the TS files in ts-addon-b, thus throwing a typecheck error.

Reproduction Case

**Link: ** https://github.com/brendenpalmer/ember-cli-typescript-typechecking-repro

Instructions listed above.

Now about that bug. What did you expect to see?

I expected to successfully run ember b in the sample app's ts-addon package without type errors

What happened instead?

Typechecking fails with the following error:

error TS6305: Output file '/Users/hmajoros/Job/ember-cli-typescript-typechecking-repro/packages/ts-addon-b/addon/index.d.ts' has not been built from source file '/Users/hmajoros/Job/ember-cli-typescript-typechecking-repro/packages/ts-addon-b/addon/index.ts'.

1 import { FOO_BAR_BAZ } from 'ts-addon-b';

[chriskrycho]

Thanks, @hmajoros! The fundamental issue here is that we don’t currently wire up the compiler API to use the build API equivalent—only to use the older watch mode equivalent, which doesn’t do any special handling for composite projects or project references:

https://github.com/typed-ember/ember-cli-typescript/blob/fbce8351895bcfdbaaf6cac1683d70c9e0ec77ab/ts/lib/typechecking/worker/index.ts#L45

This was a totally defensible choice when we made it, because as far as I recall when we did this, composite projects did not exist! However, it's something we should revisit—while working with in-repo addons more or less works correctly in the case where they're "standalone" projects, it falls over when switching to composite projects.

Other parts of the JS ecosystem do support this correctly—e.g. ts-loader's use of createSolutionBuilderWithWatchHost. We should switch over our compilation mode – potentially optionally, depending on what the user has configured.

[chriskrycho]

As noted on #1272, there is a general need for workspace support, of which this is a part. I will be building out a plan to tackle that and will link this to that once it’s in place!

[chriskrycho]

We now recommend that people switch to using ember-cli-babel for apps (as documented here) and the rollup plugin configured as part of the v2 add-on build for add-ons, in conjunction with running glint or tsc directly on their projects. Accordingly, although this should not be an issue, even if it is we will not be addressing it, as we are moving this package into maintenance mode. Thanks!