Strange behavior with Project References on

[kirill-konshin]

I have a project where I'm using ts-loader@6.1.0 with projectReferences: true and following tsconfig:

{
  "extends": "xxx/typescript/tsconfig.json",
  "compilerOptions": {
    "composite": true,
    "incremental": true,
    "tsBuildInfoFile": "./.tscache/tsconfig.tsbuildinfo",
    "target": "es5",
    "module": "commonjs",
    "baseUrl": ".",
    "rootDir": "./src",
    "outDir": "./lib",
    "declaration": true,
    "declarationDir": "./lib",
    "typeRoots": [
      "./node_modules/@types"
    ],
    "paths": {
      "web-modules-core": [
        "../core"
      ],
    }
  },
  "include": [
    "src/**/*.ts",
    "src/**/*.tsx"
  ],
  "references": [
    {
      "path": "../core"
    },
  ]
}

The project is a lerna monorepository.

On first build I get error that web-modules-core can't be resolved. Even though web-modules-core package (located in ../core) builds itself during the startup.

If I stop webpack and start it again it succeeds...

[johnnyreilly]

Could you provide a minimal reproduction repo please?

cc @andrewbranch

[kirill-konshin]

@johnnyreilly @andrewbranch I can create a private repo and add you there if this would work.

[kirill-konshin]

In fact, I was able to make it clean enough to be public: https://github.com/kirill-konshin/wmc-ts-bug

$ npm install
$ cd storybook
$ npm start

Which consistently results in

ERROR in /Users/dis/Sites/wmc-ts-bug/storybook/src/stories/Well.tsx
./src/stories/Well.tsx
[tsl] ERROR in /Users/dis/Sites/wmc-ts-bug/storybook/src/stories/Well.tsx(4,20)
      TS2307: Cannot find module 'web-modules-core'.

Then Ctrl+C to stop.

Then again:

$ npm start

This time it will work just fine.

It looks like ts-loader does not understand that web-modules-core package has been built, so Project References part worked well, you can see build artifacts in core folder.

In order to clean everything up use npx lerna run clean which will remove all build artifacts.

[johnnyreilly]

Thanks @kirill-konshin!

[kirill-konshin]

Any luck so far @johnnyreilly ?

[johnnyreilly]

I'm not looking at this myself I'm afraid - completely snowed. It's possible it may be resolved by @sheetalkamat's work on #1003

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Bessonov]

Activity!

[johnnyreilly]

Do you know anything about this @andrewbranch? I haven't looked at this at all I'm afraid..

[jleider]

I filed a similar bug a while ago: #1005 and I'm just now getting back to trying to implement project references again. As you state the first build fails but still produces the referenced projects definition files. Thats why the second build succeeds because those definition files are available at the onset of the compilation the second time around. It seems like a race condition or caching issue on ts-loader's part since the project references work just fine using tsc --build

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Bessonov]

For the community the stale bots and friends are the worst thing ever :/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Bessonov]

Let's notify everyone just for fun and stale bot. Do you like it, do you? I don't know why @johnnyreilly think that stale bot is a good idea.

[andrewbranch]

I’ve pinned it to keep the bot from marking it as stale again.

Keep in mind that ts-loader is maintained in the spare time of folks who have full-time jobs, and for many years, that has overwhelmingly been @johnnyreilly. I can’t speak for him, but I don’t currently don’t have the time or energy to devote to this issue. I understand your frustration, but, I’d wager that any tool that lets @johnnyreilly volunteer his time to this project without it taking over his life and becoming unmanageable is a net win for the community.

Expressing your frustration is ok, and it’s useful to know people still care about this issue. I’d just also remind you that a) it’s not anybody’s job to do this, and b) it can be anybody’s job to do this—it’s open source, and if you open a PR, I would make time to review it 🙂

[Bessonov]

Don't get me wrong. It was sarcastic. I'm not frustrated about no movement in this issue. But I'm very frustrated about stale bot virus in open source space. I bored to say "I'm interested to leave this issue open" and spam every subscriber or be spammed from other people who comment issues just to let it alive. From my point of view, there is no point to have stale bot - close issue or let it open. But please, stop this virus.

But, well, thanks for pinning the issue.

[appzuka]

This seems to have been fixed by PR #1136 by @sheetalkamat. This was to fix #1114 which had the same symptoms you reported. Your repo does not seem to have the symlinks present in #1114, which were reported to be causing the issue. However, the changes made to fix that issue may have also fixed yours.

I cloned your wmc-ts-bug repo, upgraded ts-loader to 8.0.0 and typescript to 3.9.3. It then builds and runs without error.

[andrewbranch]

Fantastic! Thanks for investigating @appzuka! Sounds like we can close this then.