Incorrect `webpack --watch` behavior for type-only imports when using yarn workspaces

[jtbandes]

Current behavior

Type-only imports (import type X, or import X where X is only used as a type) result in incorrect webpack --watch behavior. When files residing in workspace packages are modified, the importing code does not always get recompiled.

This is a similar issue to #36 and TypeStrong/ts-loader#1138, but that issue has been fixed and the recommendation to use "importsNotUsedAsValues": "preserve" has been removed in #516. However, issues still arise when using yarn workspaces.

It seems like enabling "importsNotUsedAsValues": "preserve" and avoiding import type might be a viable workaround for this issue, but that's not great, because import type is a core TS feature that should ideally be supported properly.

Expected behavior

Modifying a file in a workspace package should cause webpack to recompile the bundle, even if it's only used via type-only imports.

Steps to reproduce the issue

0. Check out https://github.com/jtbandes/ts-workspaces-repro. This repo uses Yarn workspaces and has two sub-packages under packages/pkg1 and packages/pkg2. The main file src/index.ts imports from these packages.

1. Run yarn install && yarn webpack --watch --progress --mode=development

2. Modify type Example1 in packages/pkg1/index.ts. Observe that webpack does not recompile src/index.ts nor display new type errors. ❌

3. Modify function Example2 in packages/pkg2/index.ts. Observe that webpack does recompile src/index.ts and display new type errors (this is not a type-only import). ✅

4. Add
   "compilerOptions": { "importsNotUsedAsValues": "preserve" } to tsconfig.json. Now, observe that changing pkg1/index.ts does cause webpack to recompile. ✅

   • Change import {Example1} from 'pkg1' to import type {Example1} from 'pkg1' in src/index.ts. Observe that changing pkg1/index.ts again does not result in a recompile. ❌ (This is because "importsNotUsedAsValues": "preserve" does not affect explicit import type imports, which are always removed.)

Issue reproduction repository

https://github.com/jtbandes/ts-workspaces-repro

Environment

• fork-ts-checker-webpack-plugin: 6.2.6
• typescript: 4.2.4
• ts-loader: 9.1.2
• webpack: 5.37.0
• os: macOS 11.3.1

[jtbandes]

Actually, in a larger repo I still don't get some type errors when changing files, even when I've changed all import type to import and enabled "importsNotUsedAsValues": "preserve". I see webpack rebuilding at the right time, but fork-ts-checker doesn't give me new TS errors. This is in a more complex workspace setup though — I'm not sure where the difference lies between my example repo and the problem we're seeing in production. See https://github.com/foxglove/studio/issues/893 for details

[piotr-oles]

Thanks for reporting that, I will take a look hopefully in this week :)

[jtbandes]

Thanks for the response! Please let me know if you need any more information or help debugging 🙂 I noticed that my example repo demonstrates a partial issue, but the workaround doesn't work in our actual real-world repo, so the issue might be more complex than I initially guessed.

I created a branch where I tried to remove all import type and enable "importsNotUsedAsValues": "preserve". But you can still see issues on this branch, by running yarn serve and editing app/types/panels.ts.

[piotr-oles]

Thanks again for the reproduction repository. I wish everyone would report issues as you did 😄
To make webpack compilation fast, we don't listen to node_modules directory changes. As you know, your projects are symlinked there by yarn workspaces.
The solution is to use project references. Thanks to your example I found one issue that will be solved in #615. When it will be merged, this is how you can set up your project: jtbandes/ts-workspaces-repro#1

[jtbandes]

Thanks! Is there a new build of fork-ts-checker that I can install to test out #615 in my repo?

[piotr-oles]

I just merged #615, should be released in 30 minutes

[jtbandes]

I tried 6.2.9, and improved some of the settings you recommended: https://github.com/foxglove/studio/compare/90cdcd3

However, I am now getting some errors when building. Strangely, the Referenced project '...' may not disable emit errors seem to change if I run yarn tsc -b packages/just-fetch before building, or if I find packages app -name \*.tsbuildinfo -delete. So they are related to some cached data — is there a chance fork-ts-checker or ts-loader is causing incorrect tsbuildinfo files to be saved? Note that I don't have noEmit set in any of these packages. However, I do override noEmit: true in the ts-loader options.

Errors from yarn serve on my branch above

ERROR in ../../app/AppSetting.ts
Module build failed (from ../../node_modules/ts-loader/index.js):
Error: TypeScript emitted no output for /Users/work/Desktop/studio/app/AppSetting.ts. The most common cause for this is having errors when building referenced projects.
    at makeSourceMapAndFinish (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:53:18)
    at successLoader (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:40:5)
    at Object.loader (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:23:5)
 @ ./telemetry.ts 7:0-61 21:41-75 22:36-64
 @ ./index.ts 19:0-51 32:30-50

ERROR in ../../app/version.ts
Module build failed (from ../../node_modules/ts-loader/index.js):
Error: TypeScript emitted no output for /Users/work/Desktop/studio/app/version.ts. The most common cause for this is having errors when building referenced projects.
    at makeSourceMapAndFinish (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:53:18)
    at successLoader (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:40:5)
    at Object.loader (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:23:5)
 @ ./index.ts 13:0-83 22:12-20 22:24-35 38:50-61 173:25-33 174:28-39 177:17-29

ERROR in ./index.ts 8:17-40
[tsl] ERROR in /Users/work/Desktop/studio/packages/ros1/tsconfig.json(8,18)
      TS6310: Referenced project '/Users/work/Desktop/studio/packages/xmlrpc' may not disable emit.

ERROR in ./index.ts 8:17-44
[tsl] ERROR in /Users/work/Desktop/studio/packages/xmlrpc/tsconfig.json(8,18)
      TS6310: Referenced project '/Users/work/Desktop/studio/packages/just-fetch' may not disable emit.

ERROR in ../../packages/log/src/index.ts
Module build failed (from ../../node_modules/ts-loader/index.js):
Error: TypeScript emitted no output for /Users/work/Desktop/studio/packages/log/src/index.ts. The most common cause for this is having errors when building referenced projects.
    at makeSourceMapAndFinish (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:53:18)
    at successLoader (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:40:5)
    at Object.loader (/Users/work/Desktop/studio/node_modules/ts-loader/dist/index.js:23:5)
 @ ./index.ts 14:0-35 21:12-28

webpack 5.36.0 compiled with 5 errors in 23889 ms

Edit: I tried removing noEmit: true from my ts-loader settings. This means ts files will actually be emitted in my local filesystem whenever running webpack serve - not really what I want, but that's ok. Now the build succeeds! 🎉 But it's also incredibly slow, even when I'm just doing an incremental build by changing one file. I'm also getting two copies of errors, one from ts-loader and one from fork-ts-checker, even though I set transpileOnly: true in my ts-loader options.

[jtbandes]

Here's an update to my example repo: jtbandes/ts-workspaces-repro@a4dde59

I enabled projectReferences: true for ts-loader, and upgraded to fork-ts-checker 6.2.9. Now I still do not see new type errors when I modify pkg1/index.ts.

[jtbandes]

I'm still having issues in my main repo that I unfortunately can't reproduce in the small test repo. If you have some time to try it out, we would really appreciate the help:

1. check out this repo @ cdd2deb
2. run yarn install and yarn serve
3. Edit app/types/panels.ts. Webpack rebuilds, but does not show any new type errors.

Note that this doesn't use build mode / project references. We don't think it's necessary because we don't run tsc directly for the main packages under desktop and app — we only use webpack for those. TypeScript and fork-ts-checker should be able to resolve imports correctly based on our webpack resolve.alias settings.

There is another branch (mentioned in a previous comment) where I tried using project references / build mode — but this is extremely slow and cpu intensive, and produces all the .js/.d.ts files on the filesystem, which we don't need for our webpack build.

[jtbandes]

^ This PR contains a workaround for the issue, so we now get type errors when changing type-only files and files in other workspace packages. However, it also seems to slow down the type checking step (is fork-ts-checker re-checking every file mentioned in include?) and ideally this workaround would not be necessary.

[piotr-oles]

It seems that there is another "bug" in the plug-in. When you run project references with ts-loader, ts-loader writes files faster than plugin and typescript uses mtime of file to decided if re-check is needed. I have some ideas how to fix it.

But I'm also thinking that maybe I could implement some exception for directories that are symlinked so project references would not be required here. I'm thinking about this, because I don't know what will be a performance impact of using project references :)

[johnnyreilly]

cc @sheetalkamat and @andrewbranch in case they're interested